On Tue, Sep 03, 2019 at 08:13:45PM +0000, Christopher Lameter wrote: > On Sat, 31 Aug 2019, Matthew Wilcox wrote: > > > > The current behavior without special alignment for these caches has been > > > in the wild for over a decade. And this is now coming up? > > > > In the wild ... and rarely enabled. When it is enabled, it may or may > > not be noticed as data corruption, or tripping other debugging asserts. > > Users then turn off the rare debugging option. > > Its enabled in all full debug session as far as I know. Fedora for > example has been running this for ages to find breakage in device drivers > etc etc. Are you telling me nobody uses the ramdisk driver on fedora? Because that's one of the affected drivers. > > > If there is an exceptional alignment requirement then that needs to be > > > communicated to the allocator. A special flag or create a special > > > kmem_cache or something. > > > > The only way I'd agree to that is if we deliberately misalign every > > allocation that doesn't have this special flag set. Because right now, > > breakage happens everywhere when these debug options are enabled, and > > the very people who need to be helped are being hurt by the debugging. > > That is customarily occurring for testing by adding "slub_debug" to the > kernel commandline (or adding debug kernel options) and since my > information is that this is done frequently (and has been for over a > decade now) I am having a hard time believing the stories of great > breakage here. These drivers were not tested with debugging on before? > Never ran with a debug kernel? Whatever is being done is clearly not enough to trigger the bug. So how about it? Create an option to slab/slub to always return misaligned memory.
