lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-Id: <20151007123351.763b98a8fe82a86ce7fdaf0c@linux-foundation.org> Date: Wed, 7 Oct 2015 12:33:51 -0700 From: Andrew Morton <akpm@...ux-foundation.org> To: Robin Murphy <robin.murphy@....com> Cc: Russell King - ARM Linux <linux@....linux.org.uk>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>, "arnd@...db.de" <arnd@...db.de>, "linux-mm@...ck.org" <linux-mm@...ck.org>, "sakari.ailus@....fi" <sakari.ailus@....fi>, "sumit.semwal@...aro.org" <sumit.semwal@...aro.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "m.szyprowski@...sung.com" <m.szyprowski@...sung.com> Subject: Re: [PATCH 4/4] dma-debug: Allow poisoning nonzero allocations On Wed, 7 Oct 2015 20:17:03 +0100 Robin Murphy <robin.murphy@....com> 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists