Re: [PATCH 1/2] mm: vmscan: remove folio_test_private() check in pageout()

[Baolin Wang]

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@xxxxxxxxxx/

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