On Wed, Jul 31, 2019 at 08:02:30AM -0400, Qian Cai wrote: > On Jul 31, 2019, at 5:53 AM, Catalin Marinas <catalin.mari...@arm.com> wrote: > > On Tue, Jul 30, 2019 at 04:22:37PM -0400, Qian Cai wrote: > >> On Tue, 2019-07-30 at 12:57 -0700, Andrew Morton wrote: > >>> On Sat, 27 Jul 2019 14:23:33 +0100 Catalin Marinas > >>> <catalin.mari...@arm.com> > >>>> --- a/Documentation/admin-guide/kernel-parameters.txt > >>>> +++ b/Documentation/admin-guide/kernel-parameters.txt > >>>> @@ -2011,6 +2011,12 @@ > >>>> Built with CONFIG_DEBUG_KMEMLEAK_DEFAULT_OFF=y, > >>>> the default is off. > >>>> > >>>> + kmemleak.mempool= > >>>> + [KNL] Boot-time tuning of the minimum kmemleak > >>>> + metadata pool size. > >>>> + Format: <int> > >>>> + Default: NR_CPUS * 4 > >>>> + > >> > >> Catalin, BTW, it is right now unable to handle a large size. I tried to > >> reserve > >> 64M (kmemleak.mempool=67108864), [...] > > It looks like the mempool cannot be created. 64M objects means a > > kmalloc(512MB) for the pool array in mempool_init_node(), so that hits > > the MAX_ORDER warning in __alloc_pages_nodemask(). > > > > Maybe the mempool tunable won't help much for your case if you need so > > many objects. It's still worth having a mempool for kmemleak but we > > could look into changing the refill logic while keeping the original > > size constant (say 1024 objects). > > Actually, kmemleak.mempool=524288 works quite well on systems I have here. > This > is more of making the code robust by error-handling a large value without the > NULL-ptr-deref below. Maybe simply just validate the value by adding upper > bound > to not trigger that warning with MAX_ORDER.
Would it work for you with a Kconfig option, similar to DEBUG_KMEMLEAK_EARLY_LOG_SIZE? > >> [ 16.192449][ T1] BUG: Unable to handle kernel data access at > >> 0xffffffffffffb2aa > > > > This doesn't seem kmemleak related from the trace. > > This only happens when passing a large kmemleak.mempool, e.g., 64M > > [ 16.193126][ T1] NIP [c000000000b2a2fc] log_early+0x8/0x160 > [ 16.193153][ T1] LR [c0000000003e6e48] kmem_cache_free+0x428/0x740 Ah, I missed the log_early() call here. It's a kmemleak bug where it isn't disabled properly in case of an error and log_early() is still called after the .text.init section was freed. I'll send a patch. -- Catalin
