Messages in this thread Patch in this message | | | From | Qian Cai <> | Subject | [PATCH] slab: skip kmemleak_object in leaks_show() | Date | Tue, 7 May 2019 20:38:38 -0400 |
| |
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(+)
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 -- 2.20.1 (Apple Git-117)
| |