Re: [PATCH] mm: Consider non-anon swap cache folios in folio_expected_ref_count()

[Kairui Song <ryncsn@gmail.com>]

On Fri, Dec 19, 2025 at 8:21 AM Wei Yang <richard.weiyang@gmail.com> wrote:
>
> On Wed, Dec 17, 2025 at 02:04:16AM +0100, David Hildenbrand (Red Hat) wrote:
> >> > >
> >> > > I am not very familiar with the memory hot-(un)plug or swapping code, so
> >> > > I am not 100% certain if this patch actually solves the root of the
> >> > > problem. I believe the issue is from shmem folios, in which case I believe
> >> > > this patch is correct. However, I couldn't think of an easy way to confirm
> >> > > that the affected folios were from shmem. I guess it could be possible that
> >> > > the root cause could be from some bug where some anonymous pages do not
> >> > > return true to folio_test_anon(). I don't think that's the case, but
> >> > > figured the MM maintainers would have a better idea of what's going on.
> >>
> >> I am not sure about if shmem in swapcache causes the issue, since
> >> the above setup does not involve shmem. +Baolin and Hugh for some insight.
> >
> >We might just push out another unrelated shmem page to swap as we create
> >memory pressure in the system I think.
> >
>
> One trivial question: currently we only put anon/shmem folio in swapcache,
> right?

For swapout, yes, the entry point to move a folio to swap space is
folio_alloc_swap, only anon and shmem can do that (vmscan.c ->
folio_test_anon && folio_test_swapbacked, and shmem.c).

Swapin is a bit different because of readahead, readahead folios are
not marked as anon / shmem (folio->mapping) until used, they do belong
to anon / shmem though, but we don't add them to the mapping until
that mapping does a swap cache lookup and use the cached folio.

Also maybe worth mentioning, swap cache lookup convention requires the
caller to lock the folio and double check folio still matches the swap
entry before use (folio_matches_swap_entry), folios there are unstable
and could no longer be a valid swap cache folio unless locked.