Re: [PATCH v4 0/3] dma-mapping, powerpc, nvme: introduce the DMA_ATTR_NO_WARN attribute

Andrew, On 08/04/2016 07:01 PM, Andrew Morton wrote: It would help to have seen an example of the error message - please always quote such things when fixing bugs. Indeed; okay. The error messages are several blocks like this one: ppc_iommu_map_sg: 11784 callbacks suppressed nvme

Re: [PATCH] DocBook: use DOCBOOKS="" to ignore DocBooks instead of IGNORE_DOCBOOKS=1

On Thu, 4 Aug 2016 11:48:26 +0300 Jani Nikula wrote: > Instead of a separate ignore flag, use the obvious DOCBOOKS="" to ignore > all DocBook files. Makes sense, applied. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of

Re: [PATCH v4 0/3] dma-mapping, powerpc, nvme: introduce the DMA_ATTR_NO_WARN attribute

On Mon, 1 Aug 2016 19:59:47 -0300 Mauricio Faria de Oliveira wrote: > This patchset introduces dma_attr DMA_ATTR_NO_WARN (just like __GFP_NOWARN), > which tells the DMA-mapping subsystem to suppress allocation failure reports. > > On some architectures allocation

Re: [PATCH 2/2] power: reset: syscon-reboot-mode: Use managed resource API

On Wed, Aug 3, 2016 at 10:04 PM, Bjorn Andersson wrote: > Use the managed resource version of reboot_mode_register(). > > Cc: John Stultz > Signed-off-by: Bjorn Andersson > --- > > John, here's a "pointer" to what I

Re: [PATCH 1/2] power: reset: reboot-mode: Add managed resource API

On Wed, Aug 3, 2016 at 10:04 PM, Bjorn Andersson wrote: > Provide managed resource version of reboot_mode_register() and > reboot_mode_unregister() to simplify implementations. > > Cc: John Stultz > Signed-off-by: Bjorn Andersson

Re: [PATCH 1/3] Documentation: dt: socfpga: Add Arria10 SD-MMC EDAC binding

On Tue, Aug 02, 2016 at 10:56:19AM -0500, ttha...@opensource.altera.com wrote: > From: Thor Thayer > > Add the device tree bindings needed to support the Altera SD-MMC > FIFO buffers EDAC on the Arria10 chip. > > Signed-off-by: Thor Thayer

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Thu, Aug 04, 2016 at 12:32:32PM -0400, Daniel Micay wrote: > On Thu, 2016-08-04 at 17:10 +0100, Mark Rutland wrote: > I wasn't talking specifically about perf. Then this is irrelevant to a discussion about limiting access to the perf interface. Hardening drivers in general is a very

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Thu, 2016-08-04 at 17:10 +0100, Mark Rutland wrote: > On Thu, Aug 04, 2016 at 11:44:28AM -0400, Daniel Micay wrote: > > > > Qualcomm's drivers might be lower quality than core kernel code, but > > they're way above the baseline set by mainline kernel drivers... > > I don't think that's true

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Thu, Aug 04, 2016 at 11:44:28AM -0400, Daniel Micay wrote: > Qualcomm's drivers might be lower quality than core kernel code, but > they're way above the baseline set by mainline kernel drivers... I don't think that's true for the arm/arm64 perf code. I think we've done a reasonable job of

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Thu, Aug 04, 2016 at 10:13:29AM -0500, Eric W. Biederman wrote: > The bits useful to the perf situation are: > - user namespaces nest. > - anyone can create a user namespace. > - a sysctl can be bound to the userns that takes local privilege to > change so you can't override it arbitrarily.

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

Peter Zijlstra writes: > On Wed, Aug 03, 2016 at 09:50:37PM -0500, Eric W. Biederman wrote: > >> What this means in practice is user namespaces can be enabled by default >> on a system, and yet you can easily disable them in a sandbox that was >> built with a user

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Thu, Aug 04, 2016 at 09:45:23AM -0400, Daniel Micay wrote: > Qualcomm's perf driver is out-of-tree along with most of their other > drivers. So you're asking us to maim upstream perf for some out of tree junk? Srously? *plonk* -- To unsubscribe from this list: send the line "unsubscribe

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Thu, 2016-08-04 at 11:28 +0100, Mark Rutland wrote: > On Wed, Aug 03, 2016 at 03:36:16PM -0400, Daniel Micay wrote: > > > > There's a lot of architecture and vendor specific perf events code > > and > > lots of bleeding edge features. On Android, a lot of the perf events > > vulnerabilities

Re: [RFC] Requirements for man page generation

On Thu, 14 Jul 2016, Mauro Carvalho Chehab wrote: > Em Thu, 14 Jul 2016 13:45:00 +0200 > Markus Heiser escreveu: > >> Hi Jonathan, hi all, >> >> I want to contribute a modified version of my man-page builder, >> but before we should elaborate

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Wed, Aug 03, 2016 at 03:36:16PM -0400, Daniel Micay wrote: > There's a lot of architecture and vendor specific perf events code and > lots of bleeding edge features. On Android, a lot of the perf events > vulnerabilities have been specific to the Qualcomm SoC platform. Other > platforms are

Re: [PATCH] DocBook: use DOCBOOKS="" to ignore DocBooks instead of IGNORE_DOCBOOKS=1

Em Thu, 4 Aug 2016 11:48:26 +0300 Jani Nikula escreveu: > Instead of a separate ignore flag, use the obvious DOCBOOKS="" to ignore > all DocBook files. This is also in line with the Sphinx build being > ignored if a non-empty DOCBOOKS make variable is specified on the

[PATCH] DocBook: use DOCBOOKS="" to ignore DocBooks instead of IGNORE_DOCBOOKS=1

Instead of a separate ignore flag, use the obvious DOCBOOKS="" to ignore all DocBook files. This is also in line with the Sphinx build being ignored if a non-empty DOCBOOKS make variable is specified on the make command line. This replaces the IGNORE_DOCBOOKS introduced in commit

[PATCH 2/2] power: reset: syscon-reboot-mode: Use managed resource API

Use the managed resource version of reboot_mode_register(). Cc: John Stultz Signed-off-by: Bjorn Andersson --- John, here's a "pointer" to what I meant with my comment on your sram-reboot-mode patch. Only compile tested though.