On Wed, 7 Oct 2015 20:17:03 +0100 Robin Murphy <robin.murphy@xxxxxxx> 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 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>