On Mon, 2009-06-22 at 14:10 +0100, Catalin Marinas wrote: > On Mon, 2009-06-22 at 14:49 +0200, Ingo Molnar wrote: > > * Vegard Nossum <vegard.nossum@xxxxxxxxx> wrote: > > > Seems to be CONFIG_DEBUG_SLAB=y that is the culprit in this case. Hm, > > > is Kconfig busted? > > > > > > lib/Kconfig.debug:301:config DEBUG_SLAB > > > lib/Kconfig.debug-302- bool "Debug slab memory allocations" > > > lib/Kconfig.debug:303: depends on DEBUG_KERNEL && SLAB && !KMEMCHECK > > > > > > fujita-config:1475:CONFIG_DEBUG_SLAB=y > > > fujita-config:1558:CONFIG_KMEMCHECK=y > > > > > > ...what gives? Pekka? > > > > Kmemleak introduced this piece of not so nice solution recently: > > > > +config DEBUG_KMEMLEAK > > + bool "Kernel memory leak detector" > > + depends on DEBUG_KERNEL && EXPERIMENTAL && (X86 || ARM) && \ > > + !MEMORY_HOTPLUG > > + select DEBUG_SLAB if SLAB > > + select SLUB_DEBUG if SLUB > > + select DEBUG_FS if SYSFS > > + select STACKTRACE if STACKTRACE_SUPPORT > > + select KALLSYMS > > > > that should be a depends line, not a select line. > > Kmemleak doesn't strictly need DEBUG_SLAB to make it a dependency. But > enabling it may reduce (in theory) the false negatives by poisoning the > allocated objects (and hence clearing any possible pointers to other > objects). But I don't have any figures to show this is the case. I'll > post a patch to drop those selects. > > BTW, wouldn't it be feasible for kbuild to ignore the select statements > if the selected config has unmet dependencies? Hmm, no idea, lets cc some relevant people here. But can we remove the select and add a config option help text to kmemleak as a short-term solution? Pekka -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
