Re: Subject: [BUG/RFC] write-open file THP cache purge can discard dirty page cache

[Gregg Leventhal]

Thanks all, it sounds like there is nothing for me to do quite yet, correct?
Also Zi Yan is correct, I meant order-0 folios.

Please let me know if there is anything I can do.
FWIW: The patch I suggested did seem to resolve the issue (based on my
testing) and did prevent my reproducer from reproducing (whereas it
repros ~instantly for me on a not patched kernel), but I (obviously)
defer to you all here.

Thanks!

On Wed, Jul 1, 2026 at 8:48 AM Pedro Falcato <pfalcato@xxxxxxx> wrote:
>
> On Wed, Jul 01, 2026 at 12:54:52PM +0100, Matthew Wilcox wrote:
> > On Tue, Jun 30, 2026 at 08:55:12PM +0100, Pedro Falcato wrote:
> > > @@ -2043,6 +2044,17 @@ static int collapse_file(struct mm_struct *mm, unsigned long addr,
> > >      */
> > >     try_to_unmap_flush();
> > >
> > > +   /*
> > > +    * If collapse looks to be successful, flush any dirty pages
> > > +    * out the page cache. With the nr_thps incremented, there won't be
> > > +    * any new writers (nor new dirties).
> > > +    */
> > > +   if (result == SCAN_SUCCEED && !is_shmem) {
> > > +           err = filemap_write_and_wait(mapping);
> > > +           if (err)
> > > +                   result = SCAN_WRITEBACK_FAIL;
> > > +   }
> >
> > Oh, the other thing is that this should be conditioned on
> > !mapping_large_folio_support().
>
> Thinking more about this, I don't think it works. On the file open side, we
> always truncate the full page cache, even if large folios are supported (due
> to possibly max folio < PMD_ORDER). So if we skip write-and-wait on such cases,
> it will be possible to fully reproduce this issue.
>
> --
> Pedro