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@xxxxxxxxxxxxx>
> > Reviewed-by: Shakeel Butt <shakeelb@xxxxxxxxxx>
> > Acked-by: Roman Gushchin <guro@xxxxxx>
>
> Cc: <stable@xxxxxxxxxxxxxxx>
>
> 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!
