mm, swap: don't spin or flood the console on a bad swap entry

A corrupt page table hands the same bogus entry to get_swap_device() on every access to the mapping, and every rejection is logged. One machine logged 6185620 copies of the same line in a few hours.

swap_dup_entry_direct() prints the same message from the fork path, once per call: the WARN_ON_ONCE() guarding it warns once, the pr_err() inside does not.

Rate limit all three prints.

Signed-off-by Breno Leitao <[email protected]>

---

A corrupt page table hands the same bogus entry to get_swap_device() on every access to the mapping, and every rejection is logged. One machine logged 6185620 copies of the same line in a few hours.

swap_dup_entry_direct() prints the same message from the fork path, once per call: the WARN_ON_ONCE() guarding it warns once, the pr_err() inside does not.

Rate limit all three prints.

Signed-off-by Breno Leitao <[email protected]>

A corrupt page table hands the same bogus entry to get_swap_device() on every access to the mapping, and every rejection is logged. One machine logged 6185620 copies of the same line in a few hours.

swap_dup_entry_direct() prints the same message from the fork path, once per call: the WARN_ON_ONCE() guarding it warns once, the pr_err() inside does not.

Rate limit all three prints.

Signed-off-by Breno Leitao <[email protected]>

---
 mm/swapfile.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

mm/swapfile.c +2 -2

index 4d4e3e3059f6b..31c8a340606bb 100644
@@ -1899,11 +1899,11 @@ struct swap_info_struct *get_swap_device(swp_entry_t entry)
 
 	return si;
 bad_nofile:
-	pr_err("%s: %s%08lx\n", __func__, Bad_file, entry.val);
+	pr_err_ratelimited("%s: %s%08lx\n", __func__, Bad_file, entry.val);
 out:
 	return NULL;
 put_out:
-	pr_err("%s: %s%08lx\n", __func__, Bad_offset, entry.val);
+	pr_err_ratelimited("%s: %s%08lx\n", __func__, Bad_offset, entry.val);
 	percpu_ref_put(&si->users);
 	return NULL;
 }

get_swap_device() returns NULL for two different things: an entry whose type names no swap device or whose offset is past the end of one, and a device that swapoff is taking away. The first never becomes valid, the second does, and callers cannot tell them apart.

Return ERR_PTR(-EIO) for the two malformed cases and keep NULL for swapoff. copy_nonpresent_pte() already reports -EIO for the same corruption on the fork path.

Callers bail out on failure either way, so switch them to IS_ERR_OR_NULL() and clear si where the cleanup path would otherwise put an ERR_PTR. No functional change.

Signed-off-by Breno Leitao <[email protected]>

---

mm/swapfile.c +4 -1

@@ -1859,7 +1859,10 @@ void folio_put_swap(struct folio *folio, struct page *page)
  * Check whether swap entry is valid in the swap device.  If so,
  * return pointer to swap_info_struct, and keep the swap entry valid
  * via preventing the swap device from being swapoff, until
- * put_swap_device() is called.  Otherwise return NULL.
+ * put_swap_device() is called.  Return NULL for an empty entry or a
+ * device that is going away, and ERR_PTR(-EIO) if the entry's type
+ * names no swap device or its offset is past the end of one. These EIOs
+ * are preceded by pr_err().
  *
  * Notice that swapoff or swapoff+swapon can still happen before the
  * percpu_ref_tryget_live() in get_swap_device() or after the

@@ -1900,12 +1903,13 @@ struct swap_info_struct *get_swap_device(swp_entry_t entry)
        return si;
 bad_nofile:

On Thu, Aug 13, 2026 at 6:02 PM Breno Leitao <[email protected]> wrote:

Do you know why we’re seeing corrupted PTEs with bad_nofile?

Does this issue still exist in mainline?

get_swap_device() returns NULL for two different things: an entry whose type names no swap device or whose offset is past the end of one, and a device that swapoff is taking away. The first never becomes valid, the second does, and callers cannot tell them apart.

Return ERR_PTR(-EIO) for the two malformed cases and keep NULL for swapoff. copy_nonpresent_pte() already reports -EIO for the same corruption on the fork path.

Callers bail out on failure either way, so switch them to IS_ERR_OR_NULL() and clear si where the cleanup path would otherwise put an ERR_PTR. No functional change.

Signed-off-by Breno Leitao <[email protected]>

get_swap_device() returns NULL for two different things: an entry whose type names no swap device or whose offset is past the end of one, and a device that swapoff is taking away. The first never becomes valid, the second does, and callers cannot tell them apart.

Return ERR_PTR(-EIO) for the two malformed cases and keep NULL for swapoff. copy_nonpresent_pte() already reports -EIO for the same corruption on the fork path.

Callers bail out on failure either way, so switch them to IS_ERR_OR_NULL() and clear si where the cleanup path would otherwise put an ERR_PTR. No functional change.

Signed-off-by Breno Leitao <[email protected]>

---
 mm/memory.c      |  6 ++++--
 mm/mincore.c     |  2 +-
 mm/shmem.c       |  2 +-
 mm/swap_state.c  |  4 ++--
 mm/swapfile.c    | 14 +++++++++-----
 mm/userfaultfd.c |  3 ++-
 mm/zswap.c       |  2 +-
 7 files changed, 20 insertions(+), 13 deletions(-)

do_swap_page() returns 0 when get_swap_device() fails, which the fault handler reads as "handled". For an entry that can never become valid the retry takes the same fault again, so the thread spins forever, retrying on the same fault.

Return VM_FAULT_SIGBUS (Bad access) for a malformed entry (pr_err() was called at get_swap_device()).

Signed-off-by Breno Leitao <[email protected]>

---
 mm/memory.c | 3 +++
 1 file changed, 3 insertions(+)

mm/memory.c +0 -0

index 7201e848129a7..fa2b3d2ad3202 100644

Quoted 19 lines · Breno Leitao

do_swap_page() returns 0 when get_swap_device() fails, which the fault handler reads as "handled". For an entry that can never become valid the retry takes the same fault again, so the thread spins forever, retrying on the same fault.

Return VM_FAULT_SIGBUS (Bad access) for a malformed entry (pr_err() was called at get_swap_device()).

Signed-off-by Breno Leitao <[email protected]>

---
 mm/memory.c | 3 +++
 1 file changed, 3 insertions(+)

mm/memory.c +0 -0

index 7201e848129a7..fa2b3d2ad3202 100644

mm/memory.c vm_fault_t do_swap_page(struct vm_fault *vmf) · line 4962

Quoted 6 lines

mm/memory.c +3 -0

@@ -4957,6 +4957,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
        /* Prevent swapoff from happening to us, and reject a bad entry. */
        si = get_swap_device(entry);
        if (IS_ERR_OR_NULL(si)) {
+               /* A malformed entry never becomes valid, so don't retry it. */
+               if (IS_ERR(si))
+                       ret = VM_FAULT_SIGBUS;

Hi Breno,

Since you now return VM_FAULT_SIGBUS, the page fault should no longer retry repeatedly. Do we still need patch 1/3, which adds the rate-limited printk?

Quoted 30 lines · Barry Song

Quoted 19 lines · Breno Leitao

do_swap_page() returns 0 when get_swap_device() fails, which the fault handler reads as "handled". For an entry that can never become valid the retry takes the same fault again, so the thread spins forever, retrying on the same fault.

Return VM_FAULT_SIGBUS (Bad access) for a malformed entry (pr_err() was called at get_swap_device()).

Signed-off-by Breno Leitao <[email protected]>

---
 mm/memory.c | 3 +++
 1 file changed, 3 insertions(+)

mm/memory.c +0 -0

index 7201e848129a7..fa2b3d2ad3202 100644

mm/memory.c vm_fault_t do_swap_page(struct vm_fault *vmf) · line 4962

Quoted 6 lines

mm/memory.c +3 -0

@@ -4957,6 +4957,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
        /* Prevent swapoff from happening to us, and reject a bad entry. */
        si = get_swap_device(entry);
        if (IS_ERR_OR_NULL(si)) {
+               /* A malformed entry never becomes valid, so don't retry it. */
+               if (IS_ERR(si))
+                       ret = VM_FAULT_SIGBUS;

Hi Breno,

Quoted 3 lines

Since you now return VM_FAULT_SIGBUS, the page fault should no longer retry repeatedly. Do we still need patch 1/3, which adds the rate-limited printk?

Yes, I still think we need it, for a few reasons:

1) A different bug could just as easily trigger the same message flood again.
2) I don't see a case where flooding the log with this message would help. If it keeps firing, something else is already broken, and the repeated message itself adds nothing useful.
3) From a monitoring perspective, I'd guess 95% of our log messages should be rate limited anyway, and this one would fall into this category.

You think this one shouldn't be ratelimited?

Quoted 15 lines

Quoted 3 lines

Since you now return VM_FAULT_SIGBUS, the page fault should no longer retry repeatedly. Do we still need patch 1/3, which adds the rate-limited printk?

Yes, I still think we need it, for a few reasons:

1) A different bug could just as easily trigger the same message flood again.
2) I don't see a case where flooding the log with this message would help. If it keeps firing, something else is already broken, and the repeated message itself adds nothing useful.
3) From a monitoring perspective, I'd guess 95% of our log messages should be rate limited anyway, and this one would fall into this category.

Quoted 1 line

You think this one shouldn't be ratelimited?

I’m fine with rate limiting. I’m just curious: now that you return SIGBUS, the PF won’t retry, so you shouldn’t get flooded with printk messages, right?

Or are there still cases where returning SIGBUS won’t prevent the printk flooding?

do_swap_page() returns 0 when get_swap_device() fails, which the fault handler reads as "handled". For an entry that can never become valid the retry takes the same fault again, so the thread spins forever, retrying on the same fault.

Return VM_FAULT_SIGBUS (Bad access) for a malformed entry (pr_err() was called at get_swap_device()).

Signed-off-by Breno Leitao <[email protected]>

---
 mm/memory.c | 3 +++
 1 file changed, 3 insertions(+)

mm/memory.c +0 -0

index 7201e848129a7..fa2b3d2ad3202 100644

do_swap_page() returns 0 when get_swap_device() fails, which the fault handler reads as "handled". For an entry that can never become valid the retry takes the same fault again, so the thread spins forever, retrying on the same fault.

Return VM_FAULT_SIGBUS (Bad access) for a malformed entry (pr_err() was called at get_swap_device()).

Signed-off-by Breno Leitao <[email protected]>

---
 mm/memory.c | 3 +++
 1 file changed, 3 insertions(+)

mm/memory.c +3 -0

index 7201e848129a7..fa2b3d2ad3202 100644
@@ -4957,6 +4957,9 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
 	/* Prevent swapoff from happening to us, and reject a bad entry. */
 	si = get_swap_device(entry);
 	if (IS_ERR_OR_NULL(si)) {
+		/* A malformed entry never becomes valid, so don't retry it. */
+		if (IS_ERR(si))
+			ret = VM_FAULT_SIGBUS;
 		si = NULL;
 		goto out;
 	}

Signature · 2 lines

-- 
2.53.0-Meta

I've seen some machines at Meta fleet that show the following type of problem:

1) It gets some weird warning:

  BUG: Bad page map in process khugepaged  pte:f000eef300000017 pmd:00000067
  addr:00007f57c0a01000 vm_flags:20200073 anon_vma:ffff88829af7c340 mapping:0000000000000000 index:7f57c0a01

The corruption is most likely the collapse/PT_RECLAIM race fixed by commit 366a4532d96f ("mm: fix the race between collapse and PT_RECLAIM under per-vma lock"). But this series is not about this one.

2) Then it floods all the monitoring of the fleet, sending the same message in the loop, crashing the our fleet kernel monitoring subsystem (which is the part that I am interested in protecting)

get_swap_device: Bad swap offset entry 3ffffffc043c5

For instance, in a host today it logged 6M in a few hours, and it is still going forever. Two things go wrong.

1) get_swap_device() prints unconditionally, unlike print_bad_pte() next door which suppresses itself with is_bad_page_map_ratelimited().

1) do_swap_page() returns 0 when get_swap_device() fails, so the fault is retried, reads the same entry and faults again. Nothing in the round trip changes the PTE.

Trying to fix it in a naive way:

PS: Sashiko flagged several pre-existing issues, and get_swap_device() returning an error opens the door to fixing some of them. For this series, I am focused in landing the basic cases first and build on top, if needed.

Quoted 21 lines · On Thu, 13 Aug 2026 03:02:19 -0700 Breno Leitao <[email protected]> wrote:

I've seen some machines at Meta fleet that show the following type of problem:

1) It gets some weird warning:

  BUG: Bad page map in process khugepaged  pte:f000eef300000017 pmd:00000067
  addr:00007f57c0a01000 vm_flags:20200073 anon_vma:ffff88829af7c340 mapping:0000000000000000 index:7f57c0a01

The corruption is most likely the collapse/PT_RECLAIM race fixed by commit 366a4532d96f ("mm: fix the race between collapse and PT_RECLAIM under per-vma lock"). But this series is not about this one.

2) Then it floods all the monitoring of the fleet, sending the same message in the loop, crashing the our fleet kernel monitoring subsystem (which is the part that I am interested in protecting)

get_swap_device: Bad swap offset entry 3ffffffc043c5

For instance, in a host today it logged 6M in a few hours, and it is still going forever. Two things go wrong.

Quoted 8 lines

1) get_swap_device() prints unconditionally, unlike print_bad_pte() next door which suppresses itself with is_bad_page_map_ratelimited().

1) do_swap_page() returns 0 when get_swap_device() fails, so the fault is retried, reads the same entry and faults again. Nothing in the round trip changes the PTE.

Trying to fix it in a naive way:

Cool.

These behaviors sound pretty obnoxious. And the patches are quite simple so hopefully the swap maintainers will make quick work of them.

I'm assuming that users of earlier kernels will want these things fixed so please let's work on identifying suitable Fixes: targets and deciding which of them should get a cc:stable.

In a spirit of experimentation I asked Gemini to identify suitable Fixes:
targets and it said

[1/3]: Fixes: 122e201211e4 ("mm, swap: get_swap_device() to get reference count of swap_info_struct")

[2/3]: Fixes: 122e201211e4 ("mm, swap: get_swap_device() to get reference count of swap_info_struct")
(and it complained that this patch doesn't fix anything)

[3/3] Fixes: 122e201211e4 ("mm, swap: get_swap_device() to get reference count of swap_info_struct")

And I cannot find such a commit anywhere, so wtf.

[2/3] is "no functional change" so ideally it simply wouldn't be present in the series - we should aim for minimal changes when fixing bugs, then leave the cleanups for later.

I think only 1/3 should be getting a Fixes: in v3. The message I am drowning in is the Bad_offset one:

get_swap_device: Bad swap offset entry 3ffffffc043c5

63d8620ecf93b5 ("mm/swapfile: use percpu_ref to serialize against concurrent swapoff") added the put_out: label with just the percpu_ref_put(), so that arm was silent. The pr_err() landed in v5.19:

So, if I need to update it, I will include:

Fixes 23b230ba8ac3 ("mm/swap: print bad swap offset entry in get_swap_device")

Cc <[email protected]>

Quoted 3 lines

[2/3] is "no functional change" so ideally it simply wouldn't be present in the series - we should aim for minimal changes when fixing bugs, then leave the cleanups for later.

I need 2/3 to expose the difference in the first place. get_swap_device() returns NULL both for a malformed entry and for a device swapoff is taking away, so no caller can tell whether the failure is worth retrying.

2/3 adds that distinction and converts the callers, but none of them act on it yet, so it is no functional change on its own.

Then 3/3 is the actual fix, now that do_swap_page() can differentiate a retry from give up.

Do you want me to squash them?

Quoted 9 lines · On Mon, 17 Aug 2026 05:21:32 -0700 Breno Leitao <[email protected]> wrote:

I think only 1/3 should be getting a Fixes: in v3. The message I am drowning in is the Bad_offset one:

get_swap_device: Bad swap offset entry 3ffffffc043c5

63d8620ecf93b5 ("mm/swapfile: use percpu_ref to serialize against concurrent swapoff") added the put_out: label with just the percpu_ref_put(), so that arm was silent. The pr_err() landed in v5.19:

Quoted 4 lines

So, if I need to update it, I will include:

Fixes 23b230ba8ac3 ("mm/swap: print bad swap offset entry in get_swap_device")

Cc <[email protected]>

OK, so you think that only [1/3] should have cc:stable?

Quoted 12 lines

Quoted 3 lines

[2/3] is "no functional change" so ideally it simply wouldn't be present in the series - we should aim for minimal changes when fixing bugs, then leave the cleanups for later.

I need 2/3 to expose the difference in the first place. get_swap_device() returns NULL both for a malformed entry and for a device swapoff is taking away, so no caller can tell whether the failure is worth retrying.

2/3 adds that distinction and converts the callers, but none of them act on it yet, so it is no functional change on its own.

Quoted 4 lines

Then 3/3 is the actual fix, now that do_swap_page() can differentiate a retry from give up.

Do you want me to squash them?

If I'm correct above then please send along [1/3] as a separate thing and I can queue it as a backportable hotfix. Then [2/3] and [3/3] as a separate two-patch series for 7.3-rcX.