From: Andrew Morton <akpm@linux-foundation.org>
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: Henry Burns <henryburns@google.com>,
Minchan Kim <minchan@kernel.org>, Nitin Gupta <ngupta@vflare.org>,
Shakeel Butt <shakeelb@google.com>,
Jonathan Adams <jwadams@google.com>,
HenryBurns <henrywolfeburns@gmail.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2 v2] mm/zsmalloc.c: Fix race condition in zs_destroy_pool
Date: Thu, 22 Aug 2019 16:23:02 -0700 [thread overview]
Message-ID: <20190822162302.6fdda379ada876e46a14a51e@linux-foundation.org> (raw)
In-Reply-To: <20190820025939.GD500@jagdpanzerIV>
On Tue, 20 Aug 2019 11:59:39 +0900 Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com> wrote:
> On (08/09/19 11:17), Henry Burns wrote:
> > In zs_destroy_pool() we call flush_work(&pool->free_work). However, we
> > have no guarantee that migration isn't happening in the background
> > at that time.
> >
> > Since migration can't directly free pages, it relies on free_work
> > being scheduled to free the pages. But there's nothing preventing an
> > in-progress migrate from queuing the work *after*
> > zs_unregister_migration() has called flush_work(). Which would mean
> > pages still pointing at the inode when we free it.
> >
> > Since we know at destroy time all objects should be free, no new
> > migrations can come in (since zs_page_isolate() fails for fully-free
> > zspages). This means it is sufficient to track a "# isolated zspages"
> > count by class, and have the destroy logic ensure all such pages have
> > drained before proceeding. Keeping that state under the class
> > spinlock keeps the logic straightforward.
> >
> > Fixes: 48b4800a1c6a ("zsmalloc: page migration support")
> > Signed-off-by: Henry Burns <henryburns@google.com>
>
> Reviewed-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
>
Thanks. So we have a couple of races which result in memory leaks? Do
we feel this is serious enough to justify a -stable backport of the
fixes?
next prev parent reply other threads:[~2019-08-22 23:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-09 18:17 [PATCH 1/2 v2] mm/zsmalloc.c: Migration can leave pages in ZS_EMPTY indefinitely Henry Burns
2019-08-09 18:17 ` [PATCH 2/2 v2] mm/zsmalloc.c: Fix race condition in zs_destroy_pool Henry Burns
2019-08-20 2:59 ` Sergey Senozhatsky
2019-08-22 23:23 ` Andrew Morton [this message]
2019-08-23 8:10 ` Henry Burns
2019-08-26 5:13 ` Sergey Senozhatsky
2019-08-20 2:53 ` [PATCH 1/2 v2] mm/zsmalloc.c: Migration can leave pages in ZS_EMPTY indefinitely Sergey Senozhatsky
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=20190822162302.6fdda379ada876e46a14a51e@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=henryburns@google.com \
--cc=henrywolfeburns@gmail.com \
--cc=jwadams@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=ngupta@vflare.org \
--cc=sergey.senozhatsky.work@gmail.com \
--cc=shakeelb@google.com \
/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).