On Wed, 2019-07-31 at 15:48 +0100, Catalin Marinas wrote: > On Wed, Jul 31, 2019 at 08:02:30AM -0400, Qian Cai wrote: > > On Jul 31, 2019, at 5:53 AM, Catalin Marinas <catalin.marinas@xxxxxxx> > > 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.marinas@ar > > > > > m.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? Yes, it should be fine. > > > > > [ 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. >
