Re: [PATCH] mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Tue, Sep 08, 2026 at 10:48:29AM +0800, Jinjiang Tu wrote:
>
> 在 2026/9/7 21:52, Lorenzo Stoakes (ARM) 写道:

> >
> > > Without this fix, our production environment could reproduce this issue
> > > about 2-5 times each month. After adding a smp_mb() before
> > > anon_vma_lock_write(anon_vma) in __anon_vma_prepare(), which is different
> > > to this patch, this issue hasn't be reproduced for one month.
> > I don't see how the smp_mb() would make any difference there, I wonder if
> > you just reduced the race window?
>
> When troubleshooting this issue, we suspected it was a memory barrier problem,
> so we added a full memory barrier like below.
>
> diff --git a/mm/rmap.c b/mm/rmap.c
> index d1819fd69938..11203f381beb 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -205,6 +205,8 @@ int __anon_vma_prepare(struct vm_area_struct *vma)
>                 allocated = anon_vma;
>         }
> +       smp_mb();
> +
>         anon_vma_lock_write(anon_vma);
>         /* page_table_lock to protect against threads */
>         spin_lock(&mm->page_table_lock);
>
>
> smp_mb() ensures that all prior loads and stores are completed
> before any subsequent loads and stores, has stricter semantics
> than smp_store_release().
>
> I used the strongest smp_mb() barrier to test in the production
> environment to confirm whether the issue was related to memory
> barriers, and to avoid falsely concluding that it wasn't a memory
> barrier issue due to the incorrect use of a weaker barrier.

Ah OK I misunderstood this (memory barriers make this easy :) so this therefore
means you've confirmed the bug fix also, as the release version is definitely
correct (I analysed it through in my reply manually and ran it through a bunch
of AI checks also to be sure).

Nice then :)

>
> > > Cc: stable@vger.kernel.org
> > > Fixes: 5c341ee1dfc8 ("mm: track the root (oldest) anon_vma")
> > I do wonder if something more recent made this at least more possible.
> >
> > A decade and a half without it being caught before seems... unlikely :)
> >
> > I wonder if the VMA locks made this more possible by (significantly)
> > increasing the ability for racing faults to occur (no mmap read lock
> > required).
>
> I mentioned it in the commit message, maybe you missed it.
>
> "We reproduced this issue in v5.10 with KSM enabled. The kernel
> doesn't merge commit cf7e7a3503df ("mm: prevent KSM from breaking
> VMA merging for new VMAs"), so there are many adjacent VMAs that
> aren't merged but are compatible for anon_vma."

Ahh ok interesting.

I do wonder if that is a better Fixes target then? But at the same time,
technically, I guess the old commit is the right one.

So yeah I think let's keep it as you've specified.

> Thanks for review. Will update the commit message and comments in v2.

Great thanks!

--
Cheers, Lorenzo