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

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

On Thu, 13 Aug 2026 03:02:19 -0700 Breno Leitao <leitao@debian.org> 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.
> 
> 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.

chatgpt didn't give me anything useful.



[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.


> 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.

Yeah. probably these are the same issues:
	https://sashiko.dev/#/patchset/20260813-swap-v2-0-4a625ccabdae@debian.org


As usual, they're all mishandled error-path things.  It's axiomatic,
really - nobody hits error-path bugs, so they never get reported so
they never get fixed.

otoh, now that these bugs are out there and known about, it's possible
that a Black Hat can find a way of exploiting them, which increases the
pressure to get these bugs addressed.