Re: [PATCH] mm: khugepaged: free xarray nodes left behind by failed collapse_file()

[Matthew Wilcox]

On Wed, Jun 17, 2026 at 11:40:28AM -0400, Rik van Riel wrote:
> On Tue, Jun 16, 2026 at 10:18 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
> >
> > On Wed, Jun 17, 2026 at 10:00:59AM +0800, Jinjiang Tu wrote:
> 
> > > I can reproduce it easily with following steps. [1]
> > > 1) create file /tmp/test_madvise_collapse and ftruncate to 4MB size, and
> > > then mmap the file
> > > 2) memset for the first 2MB
> > > 3) madvise(MADV_COLLAPSE) for the second 2MB
> > > 4) unlink the file
> >
> > Yes, but is there a problem?  That is, do we need to clear this up
> > before we get to clear_inode()?
> 
> If there is no harm in leaving this xarray node hang around until
> clear_inode() time, I agree we do not need this patch.
> 
> Are there no issues with large folios getting inserted into the
> xarray at a later time, after zapping little ones, and leaving
> the empty xarray node dangling?

That's not an issue.  The code which handles this is in
__filemap_add_folio().  You can see that we handle value (ie shadow)
entries here:

                xas_for_each_conflict(&xas, entry) {
                        old = entry;
                        if (!xa_is_value(entry)) {
                                xas_set_err(&xas, -EEXIST);
                                goto unlock;
                        }

(this loop will iterate 0 times if there are only empty nodes in the
"conflict" area)

Then we just do xas_store() which will overwrite the nodes.  That calls
xas_free_nodes() on any nodes which are overwritten.