linux-kernel - Re: [PATCH] mm: Consider non-anon swap cache folios in folio_expected_ref

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251219002134.uqgtnr43zz7vvvtd@master>
Date: Fri, 19 Dec 2025 00:21:34 +0000
From: Wei Yang <richard.weiyang@...il.com>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>
Cc: Zi Yan <ziy@...dia.com>, Bijan Tabatabai <bijan311@...il.com>,
	linux-mm@...ck.org, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, lorenzo.stoakes@...cle.com,
	Liam.Howlett@...cle.com, vbabka@...e.cz, rppt@...nel.org,
	surenb@...gle.com, mhocko@...e.com, shivankg@....com,
	Baolin Wang <baolin.wang@...ux.alibaba.com>,
	Hugh Dickins <hughd@...gle.com>, Chris Li <chrisl@...nel.org>,
	Kairui Song <kasong@...cent.com>
Subject: Re: [PATCH] mm: Consider non-anon swap cache folios in
 folio_expected_ref_count()

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?

>> 
>> 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.
>
>[...]
>
>> 
>> I agree with David. Acked-by: Zi Yan <ziy@...dia.com>
>
>Thanks for the fast review :)
>
>-- 
>Cheers
>
>David

-- 
Wei Yang
Help you, Help me