[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200728151703.GM406581@sasha-vm>
Date: Tue, 28 Jul 2020 11:17:03 -0400
From: Sasha Levin <sashal@...nel.org>
To: Muchun Song <songmuchun@...edance.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
LKML <linux-kernel@...r.kernel.org>, stable@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Shakeel Butt <shakeelb@...gle.com>,
Roman Gushchin <guro@...com>, Vlastimil Babka <vbabka@...e.cz>,
Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [External] [PATCH 4.19 76/86] mm: memcg/slab: fix memory leak at
non-root kmem_cache destroy
On Tue, Jul 28, 2020 at 08:56:41PM +0800, Muchun Song wrote:
>On Mon, Jul 27, 2020 at 10:12 PM Greg Kroah-Hartman
><gregkh@...uxfoundation.org> wrote:
>>
>> From: Muchun Song <songmuchun@...edance.com>
>>
>> commit d38a2b7a9c939e6d7329ab92b96559ccebf7b135 upstream.
>>
>> 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@...edance.com>
>> Signed-off-by: Andrew Morton <akpm@...ux-foundation.org>
>> Reviewed-by: Shakeel Butt <shakeelb@...gle.com>
>> Acked-by: Roman Gushchin <guro@...com>
>> Cc: Vlastimil Babka <vbabka@...e.cz>
>> Cc: Christoph Lameter <cl@...ux.com>
>> Cc: Pekka Enberg <penberg@...nel.org>
>> Cc: David Rientjes <rientjes@...gle.com>
>> Cc: Joonsoo Kim <iamjoonsoo.kim@....com>
>> Cc: Shakeel Butt <shakeelb@...gle.com>
>> Cc: <stable@...r.kernel.org>
>> Link: http://lkml.kernel.org/r/20200716165103.83462-1-songmuchun@bytedance.com
>> Signed-off-by: Linus Torvalds <torvalds@...ux-foundation.org>
>> Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
>>
>> ---
>> mm/slab_common.c | 35 ++++++++++++++++++++++++++++-------
>> 1 file changed, 28 insertions(+), 7 deletions(-)
>>
>> --- a/mm/slab_common.c
>> +++ b/mm/slab_common.c
>> @@ -310,6 +310,14 @@ int slab_unmergeable(struct kmem_cache *
>> if (s->refcount < 0)
>> return 1;
>>
>> +#ifdef CONFIG_MEMCG_KMEM
>> + /*
>> + * Skip the dying kmem_cache.
>> + */
>> + if (s->memcg_params.dying)
>> + return 1;
>> +#endif
>> +
>> return 0;
>> }
>>
>> @@ -832,12 +840,15 @@ static int shutdown_memcg_caches(struct
>> return 0;
>> }
>>
>> -static void flush_memcg_workqueue(struct kmem_cache *s)
>> +static void memcg_set_kmem_cache_dying(struct kmem_cache *s)
>> {
>> mutex_lock(&slab_mutex);
>> s->memcg_params.dying = true;
>> mutex_unlock(&slab_mutex);
>
>We should remove mutex_lock/unlock(&slab_mutex) here, because
>we already hold the slab_mutex from kmem_cache_destroy().
Good catch! I backported 63b02ef7dc4e ("mm: memcg/slab: synchronize
access to kmem_cache dying flag using a spinlock") instead of changing
this patch.
--
Thanks,
Sasha
Powered by blists - more mailing lists