From: Roman Gushchin <guro@fb.com>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: Muchun Song <songmuchun@bytedance.com>, <cl@linux.com>,
<penberg@kernel.org>, <rientjes@google.com>,
<iamjoonsoo.kim@lge.com>, <akpm@linux-foundation.org>,
<shakeelb@google.com>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3] mm: memcg/slab: fix memory leak at non-root kmem_cache destroy
Date: Thu, 16 Jul 2020 12:39:25 -0700 [thread overview]
Message-ID: <20200716193925.GA13387@carbon.dhcp.thefacebook.com> (raw)
In-Reply-To: <a1e6a270-e7e2-78f0-62dd-c7e9ad1b2903@suse.cz>
On Thu, Jul 16, 2020 at 07:21:42PM +0200, Vlastimil Babka wrote:
> On 7/16/20 6:51 PM, Muchun Song wrote:
> > If the kmem_cache refcount is greater than one, we should not
> > mark the root kmem_cache as dying. If we mark the root kmem_cache
> > dying incorrectly, the non-root kmem_cache can never be destroyed.
> > It resulted in memory leak when memcg was destroyed. We can use the
> > following steps to reproduce.
> >
> > 1) Use kmem_cache_create() to create a new kmem_cache named A.
> > 2) Coincidentally, the kmem_cache A is an alias for kmem_cache B,
> > so the refcount of B is just increased.
> > 3) Use kmem_cache_destroy() to destroy the kmem_cache A, just
> > decrease the B's refcount but mark the B as dying.
> > 4) Create a new memory cgroup and alloc memory from the kmem_cache
> > B. It leads to create a non-root kmem_cache for allocating memory.
> > 5) When destroy the memory cgroup created in the step 4), the
> > non-root kmem_cache can never be destroyed.
> >
> > If we repeat steps 4) and 5), this will cause a lot of memory leak.
> > So only when refcount reach zero, we mark the root kmem_cache as dying.
> >
> > Fixes: 92ee383f6daa ("mm: fix race between kmem_cache destroy, create and deactivate")
> > Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> > Reviewed-by: Shakeel Butt <shakeelb@google.com>
> > Acked-by: Roman Gushchin <guro@fb.com>
>
> Cc: <stable@vger.kernel.org>
>
> And it will need to go before the series that starts with
> mm-memcg-factor-out-memcg-and-lruvec-level-changes-out-of-__mod_lruvec_state.patch
>
> most likely causing some collisions there to be fixed up...
Collisions should be simple, as all this code with corresponding problems is
removed by the series. So in theory we can even skip applying to 5.9,
not sure if it's a good idea though.
Thanks!
prev parent reply other threads:[~2020-07-16 19:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-16 16:51 Muchun Song
2020-07-16 17:21 ` Vlastimil Babka
2020-07-16 19:39 ` Roman Gushchin [this message]
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=20200716193925.GA13387@carbon.dhcp.thefacebook.com \
--to=guro@fb.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=iamjoonsoo.kim@lge.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
--cc=shakeelb@google.com \
--cc=songmuchun@bytedance.com \
--cc=vbabka@suse.cz \
/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