Re: [PATCH 1/8] mm/rmap: improve anon_vma_clone(), unlink_anon_vmas() comments, add asserts

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

On Tue, Jan 06, 2026 at 01:04:27PM +0000, Lorenzo Stoakes wrote:
> On Tue, Jan 06, 2026 at 01:01:15PM +0000, Lorenzo Stoakes wrote:
> > On Tue, Jan 06, 2026 at 12:54:17PM +0000, Lorenzo Stoakes wrote:
> > > > > > +     /* Unfaulted is a no-op. */
> > > > > > +     VM_WARN_ON_ONCE(!vma->anon_vma && !list_empty(&vma->anon_vma_chain));
> > > >
> > > > Hmm. anon_vma_clone() calls unlink_anon_vmas() after setting
> > > > dst->anon_vma=NULL in the enomem_failure path. This warning would
> > > > imply that in such case dst->anon_vma_chain is always non-empty. But I
> > > > don't think we can always expect that... What if the very first call
> > > > to anon_vma_chain_alloc() in anon_vma_clone()'s loop failed, I think
> > > > this would result in dst->anon_vma_chain being empty, no?
> > >
> > > OK well that's a good spot, though this is never going to actually happen in
> > > reality as an allocation failure here would really be 'too small to fail'.
> > >
> > > It's a pity we have to give up a completely sensible invariant because of
> > > terribly written code for an event that will never happen.
> > >
> > > But sure will drop this then, that's awful to have to do though :/
> >
> > Actually let me just update the stupid hack exit path code to increment
> > anon_vma->num_active_vmas in this case, and do it that way (so
> > unlink_anon_vmas() drops it again).
> >
> > That actually makes the whole thing _less_ of a hack as it really makes zero
> > sense for the anon_vma not to be specified but to be working through
> > vma->anon_vma_chain, and that's a very important invariant.
>
> Scratch that, this error path ruins the whole thing (we are assigning anon_vma
> later, because of course we are). How I hate this code.
>
> Will rethink...

OK I think will add a specific partial cleanup path.

We know we are not going to hit any empty anon_vma's because we hold the
exclusive mmap write lock, so this can be radically simplified. That way we
don't have VMAs with partially established anon_vma state (both vma->anon_vma
and vma->anon_vma_chain) being sent to the core unlink function which is also an
improvement.