Re: [PATCH stable] mm/khugepaged: write all dirty file folios when collapsing

[Lance Yang]

On 2026/7/3 11:49, Baolin Wang wrote:
> On 7/3/26 12:54 AM, Pedro Falcato wrote:
> > As-is, khugepaged and writable-file opening exclude each other. A file
> > cannot be open writeable and have THPs (because the filesystem is not 
> > aware
> > of them). khugepaged will never collapse file pages for files that are
> > opened writeable. On an open(O_RDWR/O_WRONLY), the page cache for that
> > particular file is dropped. This is fine because nothing could've been
> > dirtied.
> >
> > However, there is an edge-case: collapse_file() might not be able to
> > coexist with concurrent writers, but it can coexist with dirty folios
> > (from previous writers). Therefore, the following can happen:
> >
> > open(file, O_RDWR)
> > write(file)
> > close(file)
> > madvise(file_mapping, MADV_COLLAPSE, some non-dirty range)
> > open(file, O_RDWR)
> >   nr_thps > 0
> >    truncate_inode_pages()
> >      /* THPs are cleared out, but so are the dirty folios */
> >
> > When this edge-case happens, there is data loss, as the dirty folios are
> > fully discarded.
> >
> > Fix it by fully writing back the page cache (and waiting) when collapsing
> > file THPs. Doing so provides the guarantee that no dirty folio will be
> > observed while there are active THPs. To fully ensure this is safe, the
> > invalidate_lock needs to be held while doing the writeout, so that
> > do_dentry_open()'s page cache truncation excludes this write-and-wait.
>
> Thanks for explaining the race, and it looks reasonable to me. One nit 
> below.
>
> > Cc: stable@xxxxxxxxxxxxxxx
> > Cc: Alexander Viro <viro@xxxxxxxxxxxxxxxxxx>
> > Cc: Christian Brauner <brauner@xxxxxxxxxx>
> > Cc: Jan Kara <jack@xxxxxxx>
> > Cc: Matthew Wilcox <willy@xxxxxxxxxxxxx>
> > Cc: Song Liu <song@xxxxxxxxxx>
> > Cc: Eric Hagberg <ehagberg@xxxxxxxxxxxxxx>
> > Cc: Zi Yan <ziy@xxxxxxxxxx>
> > Fixes: 99cb0dbd47a1 ("mm,thp: add read-only THP support for (non- 
> > shmem) FS")
> > Reported-by: Gregg Leventhal <gleventhal@xxxxxxxxxxxxxx>
> > Closes: https://lore.kernel.org/linux-mm/ 
> > CAFN_u7H_0ECF3jixP=T=U7AH5=Q3wQNvJMo8an3VqUDMerQfUw@xxxxxxxxxxxxxx/
> > Tested-by: Zi Yan <ziy@xxxxxxxxxx>
> > Signed-off-by: Pedro Falcato <pfalcato@xxxxxxx>
> > ---
> > This patch is written against 7.1.0 (because the code no longer exists 
> > in mainline).
> >
> > Zi, I kept your Tested-by, but I had to move some things around and
> > use the invalidate lock. Please re-test if you can.
> >
> >   mm/khugepaged.c | 39 +++++++++++++++++++++++++--------------
> >   1 file changed, 25 insertions(+), 14 deletions(-)
> >
> > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > index b8452dbdb043..0707d719a270 100644
> > --- a/mm/khugepaged.c
> > +++ b/mm/khugepaged.c
> > @@ -2094,32 +2094,43 @@ static enum scan_result collapse_file(struct 
> > mm_struct *mm, unsigned long addr,
> >           goto xa_unlocked;
> >       }
> > -    if (!is_shmem) {
> > +xa_locked:
> > +    xas_unlock_irq(&xas);
> > +xa_unlocked:
> > +
> > +    /*
> > +     * If collapse is successful, flush must be done now before copying.
> > +     * If collapse is unsuccessful, does flush actually need to be done?
> > +     * Do it anyway, to clear the state.
> > +     */
> > +    try_to_unmap_flush();
> > +
> > +    if (result == SCAN_SUCCEED && !is_shmem) {
>
> Actually, the operations below only for those mappings that do not 
> support large folios. For mappings with large folio support, 
> filemap_nr_thps() always returns 0, so the race described in the commit 
> message won't happen. We can add mapping_large_folio_support() here to 
> filter them out.
>
> if (result == SCAN_SUCCEED && !is_shmem && ! 
> mapping_large_folio_support(mapping)) {

Right! nr_thps only gets updated when !mapping_large_folio_support(mapping).

For mappings that do support large folios, writable open won't see
nr_thps > 0, so no truncate_inode_pages() for that case :)