Re: [PATCH 0/3] mm, swap: don't spin or flood the console on a bad swap entry
From: Andrew Morton
Date: Mon Aug 10 2026 - 13:20:44 EST
On Mon, 10 Aug 2026 09:26:48 -0700 Breno Leitao <leitao@xxxxxxxxxx> wrote:
> I've seen some machines at Meta flete 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 tha.
>
> 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:
Thanks. Sashiko said a bunch of things, all pre-existing.
https://sashiko.dev/#/patchset/20260810-swap-v1-0-375ef0767206@xxxxxxxxxx
You might wat to address the first one as it's on-topic for this
patchset. Ther are some swap things. The remainder are for the poor
uffd maintainers to scratch at, if inclined.