From: Vladimir Davydov <vdavydov.dev@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Christoph Lameter <cl@linux.com>,
Pekka Enberg <penberg@kernel.org>,
David Rientjes <rientjes@google.com>,
Joonsoo Kim <iamjoonsoo.kim@lge.com>,
Andrei Vagin <avagin@gmail.com>, Tejun Heo <tj@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: [PATCH] slub: fix per memcg cache leak on css offline
Date: Sat, 12 Aug 2017 21:11:34 +0300 [thread overview]
Message-ID: <20170812181134.25027-1-vdavydov.dev@gmail.com> (raw)
To avoid a possible deadlock, sysfs_slab_remove() schedules an
asynchronous work to delete sysfs entries corresponding to the kmem
cache. To ensure the cache isn't freed before the work function is
called, it takes a reference to the cache kobject. The reference is
supposed to be released by the work function. However, the work function
(sysfs_slab_remove_workfn()) does nothing in case the cache sysfs entry
has already been deleted, leaking the kobject and the corresponding
cache. This may happen on a per memcg cache destruction, because sysfs
entries of a per memcg cache are deleted on memcg offline if the cache
is empty (see __kmemcg_cache_deactivate()).
The kmemleak report looks like this:
unreferenced object 0xffff9f798a79f540 (size 32):
comm "kworker/1:4", pid 15416, jiffies 4307432429 (age 28687.554s)
hex dump (first 32 bytes):
6b 6d 61 6c 6c 6f 63 2d 31 36 28 31 35 39 39 3a kmalloc-16(1599:
6e 65 77 72 6f 6f 74 29 00 23 6b c0 ff ff ff ff newroot).#k.....
backtrace:
[<ffffffff9591d28a>] kmemleak_alloc+0x4a/0xa0
[<ffffffff9527a378>] __kmalloc_track_caller+0x148/0x2c0
[<ffffffff95499466>] kvasprintf+0x66/0xd0
[<ffffffff954995a9>] kasprintf+0x49/0x70
[<ffffffff952305c6>] memcg_create_kmem_cache+0xe6/0x160
[<ffffffff9528eaf0>] memcg_kmem_cache_create_func+0x20/0x110
[<ffffffff950cd6c5>] process_one_work+0x205/0x5d0
[<ffffffff950cdade>] worker_thread+0x4e/0x3a0
[<ffffffff950d5169>] kthread+0x109/0x140
[<ffffffff9592b8fa>] ret_from_fork+0x2a/0x40
[<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffff9f79b6136840 (size 416):
comm "kworker/1:4", pid 15416, jiffies 4307432429 (age 28687.573s)
hex dump (first 32 bytes):
40 fb 80 c2 3e 33 00 00 00 00 00 40 00 00 00 00 @...>3.....@....
00 00 00 00 00 00 00 00 10 00 00 00 10 00 00 00 ................
backtrace:
[<ffffffff9591d28a>] kmemleak_alloc+0x4a/0xa0
[<ffffffff95275bc8>] kmem_cache_alloc+0x128/0x280
[<ffffffff9522fedb>] create_cache+0x3b/0x1e0
[<ffffffff952305f8>] memcg_create_kmem_cache+0x118/0x160
[<ffffffff9528eaf0>] memcg_kmem_cache_create_func+0x20/0x110
[<ffffffff950cd6c5>] process_one_work+0x205/0x5d0
[<ffffffff950cdade>] worker_thread+0x4e/0x3a0
[<ffffffff950d5169>] kthread+0x109/0x140
[<ffffffff9592b8fa>] ret_from_fork+0x2a/0x40
[<ffffffffffffffff>] 0xffffffffffffffff
Fix the leak by adding the missing call to kobject_put() to
sysfs_slab_remove_workfn().
Signed-off-by: Vladimir Davydov <vdavydov.dev@gmail.com>
Reported-and-tested-by: Andrei Vagin <avagin@gmail.com>
Acked-by: Tejun Heo <tj@kernel.org>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Fixes: 3b7b314053d02 ("slub: make sysfs file removal asynchronous")
---
mm/slub.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/mm/slub.c b/mm/slub.c
index 364c0e769a05..0a9ee4f8dbb3 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -5642,13 +5642,14 @@ static void sysfs_slab_remove_workfn(struct work_struct *work)
* A cache is never shut down before deactivation is
* complete, so no need to worry about synchronization.
*/
- return;
+ goto out;
#ifdef CONFIG_MEMCG
kset_unregister(s->memcg_kset);
#endif
kobject_uevent(&s->kobj, KOBJ_REMOVE);
kobject_del(&s->kobj);
+out:
kobject_put(&s->kobj);
}
--
2.11.0
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next reply other threads:[~2017-08-12 18:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-12 18:11 Vladimir Davydov [this message]
2017-08-14 21:29 ` [PATCH] slub: fix per memcg cache leak on css offline David Rientjes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170812181134.25027-1-vdavydov.dev@gmail.com \
--to=vdavydov.dev@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=avagin@gmail.com \
--cc=cl@linux.com \
--cc=hannes@cmpxchg.org \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).