Re: [PATCH] mm: swap: check for xa_zero_entry() on vma in swapoff path

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Mon, Aug 11, 2025 at 05:39:32PM +0200, David Hildenbrand wrote:
>
> >
> > I could make a function that frees all new vmas and destroys the tree
> > specifically for this failure state?
>
> I think the problem is that some page tables were already copied, so we
> would have to zap them as well.

This shouldn't be too much more egregious?

The issues arise when it might be an OOM issue, but if it's a fatal signal we
can take the time to clean up.

>
> Maybe just factoring stuff from the exit_mmap() function could be one way to
> do it.

Is exit_mmap() a problem here? Or maybe I don't understand what you're getting
at.

I wonder if but can we somehow avoid telling swapoff about mm's before we're
sure the operation has completed?

We are doing:

dup_mmap()
-> copy_page_range()
-> ...
-> copy_nonpresent_pte()

And there exposing things to the swapoff.

Could we separate this out until after we're sure the fork has succeeded?
Would it really be that egregious perf-wise to do so?

Anyway - Charan - I think for the hotfix patch, you should respin with a
check for MMF_UNSTABLE, as set when this code path is active.

Then we can think about going further in untangling this mess...

Cheers, Lorenzo