Re: [PATCH] mm: prepare anon_vma before swapin rmap

[Lorenzo Stoakes <ljs@kernel.org>]

On Fri, Apr 17, 2026 at 05:03:19AM +0100, Matthew Wilcox wrote:
> On Fri, Apr 17, 2026 at 09:16:06AM +0800, ZhengYuan Huang wrote:
> > Commit a373baed5a9d ("mm: delay the check for a NULL anon_vma") moved
> > anon_vma preparation out of the generic fault path and into the fault
> > handlers that actually need to install anonymous rmap state.
> >
> > do_swap_page() was left behind. It can still restore anonymous mappings
> > via folio_add_new_anon_rmap() or folio_add_anon_rmap_ptes(), but it does
> > not call vmf_anon_prepare() first. On a VMA-lock fault this can leave
> > vma->anon_vma NULL all the way down to __folio_set_anon(), which BUG_ONs
> > on that violated invariant.
>
> Huh.  Can you share your reproducer?  I wonder if there's an equivalent
> problem with do_numa_fault().  And maybe the right solution might be
> to put the call to vmf_anon_prepare() in handle_pte_fault() instead.
>
> I'm asking because I don't quite understand how we get to this point
> without an anon_vma being assigned to this VMA.  We should allocate one on
> the first fault ... so we cannot have ever faulted, but if we've never
> faulted, how does madvise() manage to swap out a page if none has been
> allocated?

Yeah there really isn't any way this should be possible unless something
else is causing a bug here.

My recent anon_vma changes are too new for them to be the culprit I think
:))

>
> (also if you share your reproducer, perhaps someone will add it to the
> self-tests and maybe it'll prevent another bug in the future)

Yes, if this is a real bug we really need to see how this is happening.

Thanks, Lorenzo