From: Kairui Song via B4 Relay <devnull+kasong.tencent.com@kernel.org>
To: linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
Chris Li <chrisl@kernel.org>,
Kemeng Shi <shikemeng@huaweicloud.com>,
Nhat Pham <nphamcs@gmail.com>, Baoquan He <baoquan.he@linux.dev>,
Barry Song <baohua@kernel.org>,
Youngjun Park <youngjun.park@lge.com>,
Yosry Ahmed <yosry@kernel.org>,
Chengming Zhou <chengming.zhou@linux.dev>,
Usama Arif <usamaarif642@gmail.com>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Chuanhua Han <hanchuanhua@oppo.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Mani Tofigh <mt4022@columbia.edu>,
linux-kernel@vger.kernel.org, Kairui Song <kasong@tencent.com>,
Josef Bacik <josef@toxicpanda.com>,
stable@vger.kernel.org
Subject: [PATCH 1/3] mm/zswap: drop the stale zswap entry of a zero folio
Date: Fri, 30 Oct 2026 02:31:41 +0800 [thread overview]
Message-ID: <20261030-swap-fixes-v1-1-73f73a59f2fc@tencent.com> (raw)
In-Reply-To: <20261030-swap-fixes-v1-0-73f73a59f2fc@tencent.com>
From: Josef Bacik <josef@toxicpanda.com>
A folio can stay in the swap cache after zswap_store() has stored it,
when a swapin fault gets a reference on it before reclaim can remove it.
do_swap_page() maps an exclusive folio writable and, for a read fault,
keeps it in the swap cache, so it can be modified and swapped out again
to the same slot. zswap_store() handles this, it replaces the old entry,
or drops it if the store fails or zswap got disabled, "otherwise,
writeback could overwrite the new data in the swapfile".
swap_writeout() does not get as far as zswap_store() if the folio is
zero-filled now. It only sets the zero flag of the slot, and the zswap
entry with the previous contents stays in the tree and on the LRU:
reclaim fault zswap shrinker
zswap_store(D1)
swap cache hit,
map, write zeroes
swap_writeout()
zero flag set
folio reclaimed
zswap_writeback_entry()
swap_cache_alloc_folio()
decompress D1, uptodate
swap cache hit:
maps D1
Swapin looks at the zero flag first, but only when it has to read the
folio. The folio that zswap writeback leaves in the swap cache is up to
date as far as anybody can tell, so the process gets its old data back
instead of the zeroes it has written, until that folio is reclaimed.
Invalidate the zswap entries in the zero-filled case as well. The folio
is locked and in the swap cache, which keeps zswap writeback away.
Fixes: 0ca0c24e3211 ("mm: store zero pages to be swapped out in a bitmap")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
[kasong@tencent.com: fix zswap_invalidate() arguments]
Signed-off-by: Kairui Song <kasong@tencent.com>
---
mm/page_io.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/mm/page_io.c b/mm/page_io.c
index c6824fcd483e..65681eed9c80 100644
--- a/mm/page_io.c
+++ b/mm/page_io.c
@@ -224,7 +224,17 @@ int swap_writeout(struct swap_io_ctx *ctx, struct folio *folio)
* acquired internally by swap_zeromap_folio_set/clear.
*/
if (is_folio_zero_filled(folio)) {
+ swp_entry_t entry = folio->swap;
+
swap_zeromap_folio_set(folio);
+
+ /*
+ * The folio may have been stored in zswap before and dirtied
+ * again while it stayed in the swap cache. Drop the old copy,
+ * or zswap writeback would bring it back into the swap cache.
+ */
+ zswap_invalidate(swp_type(entry), swp_offset(entry),
+ folio_nr_pages(folio));
goto out_unlock;
}
--
2.56.0
next prev parent reply other threads:[~2026-10-29 18:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 18:31 [PATCH 0/3] mm/swap, zswap: fix stale zswap data and swap-in bugs Kairui Song via B4 Relay
2026-10-29 18:31 ` Kairui Song via B4 Relay [this message]
2026-10-29 19:17 ` [PATCH 1/3] mm/zswap: drop the stale zswap entry of a zero folio Johannes Weiner
2026-10-29 21:06 ` Nhat Pham
2026-10-29 21:15 ` Yosry Ahmed
2026-10-29 18:31 ` [PATCH 2/3] mm/swap: account synchronous swap reads as memory stall Kairui Song via B4 Relay
2026-10-29 21:00 ` Johannes Weiner
2026-10-29 18:31 ` [PATCH 3/3] mm, swap: fix large swap-in across swap file extents Kairui Song via B4 Relay
2026-10-29 21:21 ` Nhat Pham
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=20261030-swap-fixes-v1-1-73f73a59f2fc@tencent.com \
--to=devnull+kasong.tencent.com@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baoquan.he@linux.dev \
--cc=chengming.zhou@linux.dev \
--cc=chrisl@kernel.org \
--cc=david@kernel.org \
--cc=hanchuanhua@oppo.com \
--cc=hannes@cmpxchg.org \
--cc=josef@toxicpanda.com \
--cc=kasong@tencent.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=mt4022@columbia.edu \
--cc=nphamcs@gmail.com \
--cc=rppt@kernel.org \
--cc=shikemeng@huaweicloud.com \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=usamaarif642@gmail.com \
--cc=vbabka@kernel.org \
--cc=yosry@kernel.org \
--cc=youngjun.park@lge.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®