From: David Hildenbrand <david@redhat.com>
To: Yosry Ahmed <yosryahmed@google.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
Nhat Pham <nphamcs@gmail.com>,
Chengming Zhou <chengming.zhou@linux.dev>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Barry Song <21cnbao@gmail.com>, Chris Li <chrisl@kernel.org>,
Ryan Roberts <ryan.roberts@arm.com>,
Matthew Wilcox <willy@infradead.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: zswap: add VM_BUG_ON() if large folio swapin is attempted
Date: Thu, 6 Jun 2024 22:22:40 +0200 [thread overview]
Message-ID: <84d78362-e75c-40c8-b6c2-56d5d5292aa7@redhat.com> (raw)
In-Reply-To: <20240606184818.1566920-1-yosryahmed@google.com>
On 06.06.24 20:48, Yosry Ahmed wrote:
> With ongoing work to support large folio swapin, it is important to make
> sure we do not pass large folios to zswap_load() without implementing
> proper support.
>
> For example, if a swapin fault observes that contiguous PTEs are
> pointing to contiguous swap entries and tries to swap them in as a large
> folio, swap_read_folio() will pass in a large folio to zswap_load(), but
> zswap_load() will only effectively load the first page in the folio. If
> the first page is not in zswap, the folio will be read from disk, even
> though other pages may be in zswap.
>
> In both cases, this will lead to silent data corruption.
>
> Proper large folio swapin support needs to go into zswap before zswap
> can be enabled in a system that supports large folio swapin.
>
> Looking at callers of swap_read_folio(), it seems like they are either
> allocated from __read_swap_cache_async() or do_swap_page() in the
> SWP_SYNCHRONOUS_IO path. Both of which allocate order-0 folios, so we
> are fine for now.
>
> Add a VM_BUG_ON() in zswap_load() to make sure that we detect changes in
> the order of those allocations without proper handling of zswap.
>
> Alternatively, swap_read_folio() (or its callers) can be updated to have
> a fallback mechanism that splits large folios or reads subpages
> separately. Similar logic may be needed anyway in case part of a large
> folio is already in the swapcache and the rest of it is swapped out.
>
> Signed-off-by: Yosry Ahmed <yosryahmed@google.com>
> ---
>
> Sorry for the long CC list, I just found myself repeatedly looking at
> new series that add swap support for mTHPs / large folios, making sure
> they do not break with zswap or make incorrect assumptions. This debug
> check should give us some peace of mind. Hopefully this patch will also
> raise awareness among people who are working on this.
>
> ---
> mm/zswap.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/mm/zswap.c b/mm/zswap.c
> index b9b35ef86d9be..6007252429bb2 100644
> --- a/mm/zswap.c
> +++ b/mm/zswap.c
> @@ -1577,6 +1577,9 @@ bool zswap_load(struct folio *folio)
> if (!entry)
> return false;
>
> + /* Zswap loads do not handle large folio swapins correctly yet */
> + VM_BUG_ON(folio_test_large(folio));
> +
There is no way we could have a WARN_ON_ONCE() and recover, right?
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-06-06 20:22 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-06 18:48 Yosry Ahmed
2024-06-06 20:22 ` David Hildenbrand [this message]
2024-06-06 20:31 ` Yosry Ahmed
2024-06-06 20:54 ` Barry Song
2024-06-06 21:00 ` Yosry Ahmed
2024-06-06 21:17 ` David Hildenbrand
2024-06-06 21:30 ` Barry Song
2024-06-06 21:37 ` Yosry Ahmed
2024-06-06 21:53 ` Barry Song
2024-06-07 7:11 ` David Hildenbrand
2024-06-07 17:43 ` Yosry Ahmed
2024-06-07 18:52 ` David Hildenbrand
2024-06-07 18:58 ` Yosry Ahmed
2024-06-07 19:03 ` David Hildenbrand
2024-06-07 21:13 ` Chris Li
2024-06-07 23:14 ` Yosry Ahmed
2024-06-07 22:09 ` Barry Song
2024-06-08 0:28 ` Yosry Ahmed
2024-06-07 21:20 ` Barry Song
2024-06-07 23:17 ` Yosry Ahmed
2024-06-07 22:28 ` Barry Song
2024-06-08 0:32 ` Yosry Ahmed
2024-06-06 21:36 ` Yosry Ahmed
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=84d78362-e75c-40c8-b6c2-56d5d5292aa7@redhat.com \
--to=david@redhat.com \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=chengming.zhou@linux.dev \
--cc=chrisl@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nphamcs@gmail.com \
--cc=ryan.roberts@arm.com \
--cc=willy@infradead.org \
--cc=yosryahmed@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
all inboxes | Powered by JetHome®