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] [day] [month] [year] [list]

Message-ID: <20251220004724.b4akrh6ljreoyg5j@master>
Date: Sat, 20 Dec 2025 00:47:24 +0000
From: Wei Yang <richard.weiyang@...il.com>
To: Kairui Song <ryncsn@...il.com>
Cc: Wei Yang <richard.weiyang@...il.com>,
	"David Hildenbrand (Red Hat)" <david@...nel.org>,
	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>
Subject: Re: [PATCH] mm: Consider non-anon swap cache folios in
 folio_expected_ref_count()

On Fri, Dec 19, 2025 at 10:35:05AM +0800, Kairui Song wrote:
>On Fri, Dec 19, 2025 at 8:21 AM Wei Yang <richard.weiyang@...il.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).
>

Thanks for this information.

>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.
>

I saw this. So there is some folio which is in swapcache but no sure is
anon/shmem yet.

>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.

Thanks for this notice, will pay attention to this.

-- 
Wei Yang
Help you, Help me