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

On Mon, Aug 17, 2026 at 02:53:37PM -0700, Andrew Morton wrote:
> 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:
> > 
> > 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?

Correct, that is my suggestion. The other patches are more improvements
than a proper fix, I would say.

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

ack, I will send [1/3] with the Fixes: tag, and then [2/3] and [3/3] as
a new version of this series.

Thanks,
--breno