From: Ryan Roberts <ryan.roberts@arm.com>
To: Huang Ying <ying.huang@intel.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
David Hildenbrand <david@redhat.com>,
Miaohe Lin <linmiaohe@huawei.com>,
Hugh Dickins <hughd@google.com>, Minchan Kim <minchan@kernel.org>
Subject: Re: [PATCH] mm,swap: add document about RCU read lock and swapoff interaction
Date: Mon, 8 Apr 2024 08:23:29 +0100 [thread overview]
Message-ID: <30f09196-5152-45db-85de-12ac89c974b1@arm.com> (raw)
In-Reply-To: <20240407065450.498821-1-ying.huang@intel.com>
On 07/04/2024 07:54, Huang Ying wrote:
> During reviewing a patch to fix the race condition between
> free_swap_and_cache() and swapoff() [1], it was found that the
> document about how to prevent racing with swapoff isn't clear enough.
> Especially RCU read lock can prevent swapoff from freeing data
> structures. So, the document is added as comments.
>
> [1] https://lore.kernel.org/linux-mm/c8fe62d0-78b8-527a-5bef-ee663ccdc37a@huawei.com/
>
> Signed-off-by: "Huang, Ying" <ying.huang@intel.com>
> Cc: Ryan Roberts <ryan.roberts@arm.com>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Miaohe Lin <linmiaohe@huawei.com>
> Cc: Hugh Dickins <hughd@google.com>
> Cc: Minchan Kim <minchan@kernel.org>
LGTM!
Reviewed-by: Ryan Roberts <ryan.roberts@arm.com>
> ---
> mm/swapfile.c | 26 +++++++++++++-------------
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 4919423cce76..6925462406fa 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -1226,16 +1226,15 @@ static unsigned char __swap_entry_free_locked(struct swap_info_struct *p,
>
> /*
> * When we get a swap entry, if there aren't some other ways to
> - * prevent swapoff, such as the folio in swap cache is locked, page
> - * table lock is held, etc., the swap entry may become invalid because
> - * of swapoff. Then, we need to enclose all swap related functions
> - * with get_swap_device() and put_swap_device(), unless the swap
> - * functions call get/put_swap_device() by themselves.
> + * prevent swapoff, such as the folio in swap cache is locked, RCU
> + * reader side is locked, etc., the swap entry may become invalid
> + * because of swapoff. Then, we need to enclose all swap related
> + * functions with get_swap_device() and put_swap_device(), unless the
> + * swap functions call get/put_swap_device() by themselves.
> *
> - * Note that when only holding the PTL, swapoff might succeed immediately
> - * after freeing a swap entry. Therefore, immediately after
> - * __swap_entry_free(), the swap info might become stale and should not
> - * be touched without a prior get_swap_device().
> + * RCU reader side lock (including any spinlock) is sufficient to
> + * prevent swapoff, because synchronize_rcu() is called in swapoff()
> + * before freeing data structures.
> *
> * Check whether swap entry is valid in the swap device. If so,
> * return pointer to swap_info_struct, and keep the swap entry valid
> @@ -2495,10 +2494,11 @@ SYSCALL_DEFINE1(swapoff, const char __user *, specialfile)
>
> /*
> * Wait for swap operations protected by get/put_swap_device()
> - * to complete.
> - *
> - * We need synchronize_rcu() here to protect the accessing to
> - * the swap cache data structure.
> + * to complete. Because of synchronize_rcu() here, all swap
> + * operations protected by RCU reader side lock (including any
> + * spinlock) will be waited too. This makes it easy to
> + * prevent folio_test_swapcache() and the following swap cache
> + * operations from racing with swapoff.
> */
> percpu_ref_kill(&p->users);
> synchronize_rcu();
next prev parent reply other threads:[~2024-04-08 7:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-07 6:54 Huang Ying
2024-04-08 7:23 ` Ryan Roberts [this message]
2024-04-08 7:41 ` David Hildenbrand
2024-04-10 7:58 ` Miaohe Lin
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=30f09196-5152-45db-85de-12ac89c974b1@arm.com \
--to=ryan.roberts@arm.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=ying.huang@intel.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