On Wed, 7 Oct 2015 20:17:03 +0100 Robin Murphy [off-list ref] wrote:

quoted

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 feature probably does warrant finer-grained control to be 
really practical. Having thought about it some more, it's also probably 
wrong that this doesn't respect the dma_debug_driver filter, given that 
it is actually invasive; in fixing that, how about if it also *only* 
applied when a specific driver is filtered? Then there would be no 
problematic "break anything and everything" mode, and the existing 
debugfs controls should suffice.

Yes, this should respect the driver filtering.

On reflection...

The patch poisons dma buffers if CONFIG_DMA_API_DEBUG and if __GFP_ZERO
wasn't explicitly used.  I'm rather surprised that the dma-debug code
didn't do this from day one.

I'd be inclined to enable this buffer-poisoning by default.  Do you
have a feeling for how much overhead that will add?  Presumably not
much, if __GFP_ZERO is acceptable.

Also, how about we remove CONFIG_DMA_API_DEBUG_POISON and switch to a
debugfs knob?


btw, the documentation could do with a bit of a tune-up.  The comments
in dma-debug.c regarding driver filtering are non-existent. 
Documentation/kernel-parameters.txt says "The filter can be disabled or
changed to another driver later using sysfs" but
Documentation/DMA-API.txt talks about debugfs.