Re: [PATCH 0/3] mm, swap: don't spin or flood the console on a bad swap entry

[Andrew Morton <akpm@linux-foundation.org>]

On Mon, 10 Aug 2026 09:26:48 -0700 Breno Leitao <leitao@debian.org> 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@debian.org

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.