linux-kernel - Re: [PATCH 1/2] mm: vmscan: remove folio_test

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: <41c98144-de4c-4b46-b842-dfc03e3b0cca@linux.alibaba.com>
Date: Thu, 18 Sep 2025 10:45:37 +0800
From: Baolin Wang <baolin.wang@...ux.alibaba.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: akpm@...ux-foundation.org, hannes@...xchg.org, david@...hat.com,
 mhocko@...nel.org, zhengqi.arch@...edance.com, shakeel.butt@...ux.dev,
 lorenzo.stoakes@...cle.com, hughd@...gle.com, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] mm: vmscan: remove folio_test_private() check in
 pageout()



On 2025/9/16 04:47, Matthew Wilcox wrote:
> On Sat, Sep 13, 2025 at 11:04:48AM +0800, Baolin Wang wrote:
>> On 2025/9/12 23:21, Matthew Wilcox wrote:
>>> On Fri, Sep 12, 2025 at 11:45:07AM +0800, Baolin Wang wrote:
>>>> @@ -697,22 +697,8 @@ static pageout_t pageout(struct folio *folio, struct address_space *mapping,
>>>>    	 * swap_backing_dev_info is bust: it doesn't reflect the
>>>>    	 * congestion state of the swapdevs.  Easy to fix, if needed.
>>>>    	 */
>>>> -	if (!is_page_cache_freeable(folio))
>>>> +	if (!is_page_cache_freeable(folio) || !mapping)
>>>>    		return PAGE_KEEP;
>>>
>>> I feel like we need to keep the comment (assuming it's still true ...
>>> which it probably is, although there's nobody who would think to update
>>> this comment if it became no longer true).  I would certainly wonder why
>>> we can have this !mapping test.
>>
>> I think the !mapping check is still needed here because the tmpfs/shmem
>> folios truncation might race with folio reclamation, see shmem_undo_range().

Sorry for noise. tmpfs/shmem folios will be clean after calling 
truncate_inode_folio().

> I agree that we still need the !mapping check.  But it needs this comment
> that you're deleting, because it's not obvious why we'd have a dirty
> folio with a NULL mapping on the LRU list.

As I discussed with Hugh in another thread[1], the issue of a folio 
being dirty but having a NULL mapping was fixed by commit a2b345642f530 
("Fix dirty page accounting leak with ext3 data=journal"). I can hardly 
believe this kind of situation can still occur nowadays. Anyway, let me 
leave a warning comment here.

[1] 
https://lore.kernel.org/all/1111883c-974f-e4da-a38f-bb3d337185ad@google.com/

>>>> -		/*
>>>> -		 * Some data journaling orphaned folios can have
>>>> -		 * folio->mapping == NULL while being dirty with clean buffers.
>>>> -		 */