* + mm-swap-fix-large-swap-in-across-swap-file-extents.patch added to mm-new branch
@ 2026-11-04 7:26 Andrew Morton
0 siblings, 0 replies; only message in thread
From: Andrew Morton @ 2026-11-04 7:26 UTC (permalink / raw)
To: mm-commits, youngjun.park, yosry, vbabka, usamaarif642, surenb,
stable, shikemeng, ryncsn, rppt, nphamcs, neil, mt4022, mhocko,
ljs, liam, kasong, josef, hch, hannes, hanchuanhua, david, chrisl,
chengming.zhou, baoquan.he, baohua, mason, akpm
The patch titled
Subject: mm, swap: fix large swap-in across swap file extents
has been added to the -mm mm-new branch. Its filename is
mm-swap-fix-large-swap-in-across-swap-file-extents.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-swap-fix-large-swap-in-across-swap-file-extents.patch
This patch will later appear in the mm-new branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Note, mm-new is a provisional staging ground for work-in-progress
patches, and acceptance into mm-new is a notification for others take
notice and to finish up reviews. Please do not hesitate to respond to
review feedback and post updated versions to replace or incrementally
fixup patches in mm-new.
The mm-new branch of mm.git is not included in linux-next
If a few days of testing in mm-new is successful, the patch will me moved
into mm.git's mm-unstable branch, which is included in linux-next
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days
------------------------------------------------------
From: Chris Mason <mason@kernel.org>
Subject: mm, swap: fix large swap-in across swap file extents
Date: Wed, 04 Nov 2026 00:18:15 +0800
A page fault can give an unprivileged process blocks of other users'
files instead of its own swapped-out data. This affects systems with a
swap file on a synchronous block device, such as brd or zram. For an
anonymous mapping it also takes a huge page size below the PMD size
(mTHP), such as 64 KiB, that is enabled for anonymous memory.
A swap area is divided into slots of one page each. A swap file is a
regular file, so adjacent swap slots can lie in two extents, far apart
on disk. A folio is read from swap with a single bio that starts at the
sector of the folio's first slot. So all slots of a large folio must be
contiguous on disk.
The swap allocator knows this: it only hands out a run of slots for a
large folio if the swap area is a block device (SWP_BLKDEV).
The swap-in path does not. On a synchronous device (SWP_SYNCHRONOUS_IO),
one that always completes I/O in the submitter's context, do_swap_page()
can read several swapped-out pages as one large folio (a large swap-in).
thp_swapin_suitable_orders() makes that decision, and looks only at the
swap offsets (the slot numbers) in the page table.
Pages that were swapped out one at a time can end up in consecutive,
aligned slots, and are then read as one large folio. If the extent of
the first slot ends inside that folio, the rest of the folio is filled
from the blocks that follow the extent on disk. These blocks can belong
to other files.
Reproduced with a fragmented swap file on brd and 64 KiB folios enabled.
After single pages were swapped out, a fault returned blocks of a
root-owned file with mode 0600.
Fix this by allowing a large swap-in only when SWP_BLKDEV is set.
Known gaps:
- A swap file on zram, brd, pmem or btt is now read one page at a time,
even where its slots lie in one extent. Its swpin counters in
/sys/kernel/mm/transparent_hugepage/hugepages-*/stats stay at 0.
- There could be devices with SWP_SYNCHRONOUS_IO but not
SWP_BLKDEV, so the new check would have to let that device pass.
[kasong@tencent.com: simplify the note about the unmerged xswap patch]
Link: https://lore.kernel.org/20261104-swap-fixes-v2-2-204be064be5b@tencent.com
Fixes: 242d12c98174 ("mm: support large folios swap-in for sync io devices")
Signed-off-by: Chris Mason <mason@kernel.org>
Signed-off-by: Kairui Song <kasong@tencent.com>
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Nhat Pham <nphamcs@gmail.com>
Cc: Chris Li <chrisl@kernel.org>
Cc: Kemeng Shi <shikemeng@huaweicloud.com>
Cc: Baoquan He <baoquan.he@linux.dev>
Cc: Barry Song <baohua@kernel.org>
Cc: Youngjun Park <youngjun.park@lge.com>
Cc: Usama Arif <usamaarif642@gmail.com>
Cc: Chengming Zhou <chengming.zhou@linux.dev>
Cc: Yosry Ahmed <yosry@kernel.org>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Chuanhua Han <hanchuanhua@oppo.com>
Cc: Mani Tofigh <mt4022@columbia.edu>
Cc: NeilBrown <neil@brown.name>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Josef Bacik <josef@toxicpanda.com>
Cc: Kairui Song <ryncsn@gmail.com>
Cc: <stable@vger.kernel.org>
---
mm/memory.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/mm/memory.c~mm-swap-fix-large-swap-in-across-swap-file-extents
+++ a/mm/memory.c
@@ -4830,7 +4830,8 @@ static inline unsigned long thp_swap_sui
return orders;
}
-static unsigned long thp_swapin_suitable_orders(struct vm_fault *vmf)
+static unsigned long thp_swapin_suitable_orders(struct swap_info_struct *si,
+ struct vm_fault *vmf)
{
struct vm_area_struct *vma = vmf->vma;
unsigned long orders;
@@ -4855,6 +4856,14 @@ static unsigned long thp_swapin_suitable
if (!zswap_never_enabled())
return 0;
+ /*
+ * Neighbouring slots of a swap file can lie in two extents, and a folio
+ * is read with one bio. The flag is set in swapon() and stays, so the
+ * race is benign.
+ */
+ if (!data_race(si->flags & SWP_BLKDEV))
+ return 0;
+
entry = softleaf_from_pte(vmf->orig_pte);
/*
* Get a list of all the (large) orders below PMD_ORDER that are enabled
@@ -4891,7 +4900,8 @@ static unsigned long thp_swapin_suitable
return orders;
}
#else /* !CONFIG_TRANSPARENT_HUGEPAGE */
-static unsigned long thp_swapin_suitable_orders(struct vm_fault *vmf)
+static unsigned long thp_swapin_suitable_orders(struct swap_info_struct *si,
+ struct vm_fault *vmf)
{
return 0;
}
@@ -5037,7 +5047,7 @@ vm_fault_t do_swap_page(struct vm_fault
/* Swapin bypasses readahead for SWP_SYNCHRONOUS_IO devices and zswap */
if (swap_entry_synchronous(si, entry))
folio = swapin_sync(entry, GFP_HIGHUSER_MOVABLE,
- thp_swapin_suitable_orders(vmf) | BIT(0),
+ thp_swapin_suitable_orders(si, vmf) | BIT(0),
vmf, NULL, 0);
else
folio = swapin_readahead(entry, GFP_HIGHUSER_MOVABLE, vmf);
_
Patches currently in -mm which might be from mason@kernel.org are
mm-swap-fix-large-swap-in-across-swap-file-extents.patch
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2026-11-04 7:26 UTC | newest]
Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-11-04 7:26 + mm-swap-fix-large-swap-in-across-swap-file-extents.patch added to mm-new branch Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox