On Wed, 7 Oct 2015 20:17:03 +0100 Robin Murphy wrote:
> > It might be helpful to provide a runtime knob as well - having to
> > rebuild&reinstall just to enable/disable this feature is a bit painful.
>
> Good point - there's always the global DMA debug disable knob, but this
> particular featur
On 29/09/15 22:27, Andrew Morton wrote:
[...]
If I'm understanding things correctly, some allocators zero the memory
by default and others do not. And we have an unknown number of drivers
which are assuming that the memory is zeroed.
Correct?
That's precisely the motivation here, yes.
If so
On Fri, 25 Sep 2015 18:35:39 +0100 Robin Murphy wrote:
> Hi Russell,
>
> On 25/09/15 13:44, Russell King - ARM Linux wrote:
> > On Fri, Sep 25, 2015 at 01:15:46PM +0100, Robin Murphy wrote:
> >> Since some dma_alloc_coherent implementations return a zeroed buffer
> >> regardless of whether __GFP
Hi Russell,
On 25/09/15 13:44, Russell King - ARM Linux wrote:
On Fri, Sep 25, 2015 at 01:15:46PM +0100, Robin Murphy wrote:
Since some dma_alloc_coherent implementations return a zeroed buffer
regardless of whether __GFP_ZERO is passed, there exist drivers which
are implicitly dependent on thi
On Fri, Sep 25, 2015 at 01:15:46PM +0100, Robin Murphy wrote:
> Since some dma_alloc_coherent implementations return a zeroed buffer
> regardless of whether __GFP_ZERO is passed, there exist drivers which
> are implicitly dependent on this and pass otherwise uninitialised
> buffers to hardware. Thi
Since some dma_alloc_coherent implementations return a zeroed buffer
regardless of whether __GFP_ZERO is passed, there exist drivers which
are implicitly dependent on this and pass otherwise uninitialised
buffers to hardware. This can lead to subtle and awkward-to-debug issues
using those drivers o
6 matches
Mail list logo
