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

Hello Andrew,

On Thu, Aug 13, 2026 at 01:34:55PM -0700, Andrew Morton wrote:
> 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.
> > 
> > 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.

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

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