Re: [PATCH] mm/swap: fix swap_cache_get_folio() returning a folio that left the swap cache

[Jiayuan Chen]

Hi Andrew,

On 10/16/26 9:40 AM, Andrew Morton wrote:
> On Thu, 15 Oct 2026 14:05:27 +0800 Jiayuan Chen <jiayuan.chen@xxxxxxxxx> wrote:
[...]
> So CPU 0 writes to a folio it doesn't own: it may clear PG_readahead and
> takes the folio lock of someone else's page, before
> folio_matches_swap_entry() finds out the folio is not ours.
>
> Recheck the slot after folio_try_get() and retry if it no longer holds
> this folio.
> Thanks.
>
> As always, when fixing a bug please fully describe the worst-case
> userspace-visible runtime effects of that bug.
>
> I asked $LLM for this and was told
>
> : When the race occurs, a swap fault can acquire a reference to a
> : physical page that has been freed and reused for an unrelated purpose,
> : potentially by another process.  The fault handler may then clear that
> : page's PG_readahead/PG_reclaim flag, wait on or acquire its folio lock,
> : and potentially attempt to remove it from an unrelated swap cache.
> :
> : These operations can interfere with unrelated workloads and may cause
> : unexpected stalls, impaired reclaim or writeback, and potentially
> : system hangs.  The subsequent swap-entry validation normally prevents


I don't see a way to a system hang: the folio lock waiter is woken when
the real owner unlocks, so the worst case is a stall. I suggest
dropping "and potentially system hangs".


Writeback itself is not affected, only the PG_reclaim hint on where to
put the folio after writeback. So "impaired reclaim or writeback" ->
"impaired reclaim".

So I'd suggest:

  : When the race occurs, a swap fault can acquire a reference to a
  : physical page that has been freed and reused for an unrelated purpose,
  : potentially by another process.  The fault handler may then clear that
  : page's PG_readahead/PG_reclaim flag, wait on or acquire its folio lock,
  : and potentially attempt to remove it from an unrelated swap cache.
  :
  : These operations can interfere with unrelated workloads and may cause
  : unexpected stalls and impaired reclaim.  The subsequent swap-entry
  : validation normally prevents the wrong folio from being mapped into
  : the faulting process, and neither data corruption nor a kernel crash
  : has been demonstrated.


> : the wrong folio from being mapped into the faulting process, and
> : neither data corruption nor a kernel crash has been demonstrated.
>
> Do you agree with this?  OK with me adding this to your changelog?
>
> > Fixes: 8578e0c00dcf ("mm, swap: use the swap table for the swap cache and switch API")
> Given the above, I suggest adding cc:stable.
>
> Do you and maintainers agree?


Agreed for me.