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

[Jiayuan Chen <jiayuan.chen@linux.dev>]

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@linux.dev> 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.