On Thu, 4 Aug 2016 21:17:27 -0300 Mauricio Faria de Oliveira
wrote:
> > [snip] An alternative (and more idiomatic) fix would be to
> > change the blk_rq_map_sg() interface to permit passing down some
> > foo_NOWARN flag and propagating that down the stack into
> > ppc_iommu_map_sg(). Was this a
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 000
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 a message to majord...@
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 failures are reported with err
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 meant with my comment on your
> sram-reboot-mode patch. Only compile tested thou
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
> ---
>
> John, here's a "pointer" to what I meant with my comment
On Tue, 2016-07-12 at 17:18 -0700, Joe Perches wrote:
> Because Linus may still be reading source code on greenbar paper
> instead of color terminals with code syntax highlighting and
> appropriate font decorations.
>
> Link:
> http://lkml.kernel.org/r/ca+55afyqyjerovmssosks7pesszbr4vnp-3quuwhqk4
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
> ---
> .../bindings/arm/altera/socfpga-eccmgr.txt
> My claim was not that the mainline code was impressively perfect, but
> rather that the vendor code was worse, countering a prior claim
> otherwise. Hence, reality.
You're arguing with a straw man.
I was responding to a comment about out-of-tree code, not generic
architecture perf drivers vs. a
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 interestin
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 fo
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 tes
On Thu, Aug 04, 2016 at 11:44:28AM -0400, Daniel Micay wrote:
> This feature doesn't come from Android. The perf events subsystem in the
> mainline kernel is packed full of vulnerabilities too.
Uhh, not so much. I spend a _lot_ of time a while back to get the core
and x86 solid. I could run the
On Thu, 2016-08-04 at 16:11 +0200, Peter Zijlstra wrote:
> 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
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.
>
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 namespace.
>>
>> I named the ne
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 linux
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 hav
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 what we need in more detail.
>> We have two use-cases
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 like
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 make
> command line.
>
> T
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 547218864afb2745
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 namespace.
>
> I named the new sysctls in my patch:
> /proc/sy
23 matches
Mail list logo
