From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Henry Burns <henryburns@google.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Minchan Kim <minchan@kernel.org>, Nitin Gupta <ngupta@vflare.org>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
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: Tue, 20 Aug 2019 11:59:39 +0900 [thread overview]
Message-ID: <20190820025939.GD500@jagdpanzerIV> (raw)
In-Reply-To: <20190809181751.219326-2-henryburns@google.com>
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>
+ Andrew
-ss
next prev parent reply other threads:[~2019-08-20 2:59 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 [this message]
2019-08-22 23:23 ` Andrew Morton
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=20190820025939.GD500@jagdpanzerIV \
--to=sergey.senozhatsky.work@gmail.com \
--cc=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=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.