On Mon, Oct 14, 2019 at 07:50:21AM -0400, Theodore Y. Ts'o wrote: > On Mon, Oct 14, 2019 at 08:03:14AM +0100, Catalin Marinas wrote: > > Thanks for the report. I have a fix already: > > > > http://lkml.kernel.org/r/[email protected] > > > > I was hoping Andrew had sent it to Linus before -rc3 but it doesn't seem > > to be in mainline yet. > > Thanks for the pointer to the fix! Does that mean that the workaround > is to increase the kmemleak pool size? I had been using the default > (16000) and it seems surprising that that it wasn't enough to even get > the kernel through a standard boot sequence. Should we perhaps > increase the default mempool size?
In your case, CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y, so it disables itself irrespective of the pool size and trips over the bug. Even with default off, it still involves the clean-up since kmemleak needs to track early allocations in case it is turned on by the kmemleak=on cmdline option. So I think 16000 is sufficient in your case, the default-off triggered the bug (well, unless you find in the logs "kmemleak: Memory pool empty, consider increasing CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE"). -- Catalin
