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

[Baolin Wang <baolin.wang@linux.alibaba.com>]

On 2025/12/17 09:04, 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.
> 
>>
>> But David also mentioned that in __read_swap_cache_async() there is a 
>> chance
>> that anon folio in swapcache can have anon flag not set yet. +Chris 
>> and Kairui
>> for more analysis.
> 
> Right, when we swapin an anon folio and did not map it into the page 
> table yet. Likely we can trigger something similar when we proactively 
> read a shmem page from swap into the swapcache.
> 
> So it's unclear "where" a swapcache page belongs to until we move it to 
> its owner (anon / shmem), which is also why I cannot judge easily from
> 
> [   49.641309] migrating pfn b12f25 failed ret:7
> [   49.641310] page: refcount:2 mapcount:0 mapping:0000000033bd8fe2 
> index:0x7f404d925 pfn:0xb12f25
> [   49.641311] aops:swap_aops
> [   49.641313] flags: 0x300000000030508(uptodate|active|owner_priv_1| 
> reclaim|swapbacked|node=0|zone=3)
> [   49.641314] raw: 0300000000030508 ffffed312c4bc908 ffffed312c4bc9c8 
> 0000000000000000
> [   49.641315] raw: 00000007f404d925 00000000000c823b 00000002ffffffff 
> 0000000000000000
> [   49.641315] page dumped because: migration failure
> 
> What exactly that was.
> 
> It was certainly an order-0 folio.

Thanks David for the explanation. It completely makes sense to me. So 
feel free to add:

Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>