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

[Matthew Wilcox <willy@infradead.org>]

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?

(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)