| Message ID | 20190514144741.39460-1-cai@lca.pw (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [RESEND] slab: skip kmemleak_object in leaks_show() | expand |
On Tue, 14 May 2019, Qian Cai wrote: > Running tests on a debug kernel will usually generate a large number of > kmemleak objects. > > # grep kmemleak /proc/slabinfo > kmemleak_object 2243606 3436210 ... > > As the result, reading /proc/slab_allocators could easily loop forever > while processing the kmemleak_object cache and any additional freeing or > allocating objects will trigger a reprocessing. To make a situation > worse, soft-lockups could easily happen in this sitatuion which will > call printk() to allocate more kmemleak objects to guarantee a livelock. > > Since kmemleak_object has a single call site (create_object()), there > isn't much new information compared with slabinfo. Just skip it. > > Signed-off-by: Qian Cai <cai@lca.pw> I assume this is now obsolete since commit 7878c231dae0 ("slab: remove /proc/slab_allocators").
diff --git a/mm/slab.c b/mm/slab.c index 20f318f4f56e..85d1d223f879 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -4285,6 +4285,15 @@ static int leaks_show(struct seq_file *m, void *p) if (!(cachep->flags & SLAB_RED_ZONE)) return 0; + /* + * /proc/slabinfo has the same information, so skip kmemleak here due to + * a high volume and its RCU free could make cachep->store_user_clean + * dirty all the time. + */ + if (IS_ENABLED(CONFIG_DEBUG_KMEMLEAK) && + !strcmp("kmemleak_object", cachep->name)) + return 0; + /* * Set store_user_clean and start to grab stored user information * for all objects on this cache. If some alloc/free requests comes
Running tests on a debug kernel will usually generate a large number of kmemleak objects. # grep kmemleak /proc/slabinfo kmemleak_object 2243606 3436210 ... As the result, reading /proc/slab_allocators could easily loop forever while processing the kmemleak_object cache and any additional freeing or allocating objects will trigger a reprocessing. To make a situation worse, soft-lockups could easily happen in this sitatuion which will call printk() to allocate more kmemleak objects to guarantee a livelock. Since kmemleak_object has a single call site (create_object()), there isn't much new information compared with slabinfo. Just skip it. Signed-off-by: Qian Cai <cai@lca.pw> --- mm/slab.c | 9 +++++++++ 1 file changed, 9 insertions(+)