Re: [PATCH v2 1/2] mm/memory: recheck PG_uptodate after ->page_mkwrite()

[Matthew Wilcox <willy@infradead.org>]

On Tue, Nov 10, 2026 at 10:38:34AM +0000, Kiryl Shutsemau wrote:
> On Mon, Nov 09, 2026 at 08:30:47PM +0000, Matthew Wilcox wrote:
> > On Mon, Nov 09, 2026 at 12:04:01PM +0000, Kiryl Shutsemau (Meta) wrote:
> > > do_shared_fault() unlocks the folio around ->page_mkwrite(). Writeback
> > > can lock it in that window, fail, and clear PG_uptodate with the folio
> > > left in the page cache. ecryptfs_writepages() does this when encryption
> > > fails. filemap_page_mkwrite() relocks the folio and checks only
> > > ->mapping, so the fault maps a folio that is not uptodate:
> > 
> > Filesystems that do this are buggy.  They shuld be fixed, not worked
> > around like this.
> 
> Fair. What is your take on the way out?
> 
> Is there a timeline for the filesystem fixes?
> 
> Until they land, mm should still not map a folio that is not uptodate.
> 
> Would WARN_ON_ONCE() and SIGBUS, like the other checks in 2/2, work for
> you? It flags the buggy filesystem instead of hiding it.

It doesn't matter which way round the race ends up; if a filesystem marks
a mapped folio as !uptodate, there are other VM assertions that will
trip eventually.  This is one of those cases where we should ignore the
bot because it doesn't quite know enough.