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

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

On Mon, Sep 07, 2026 at 10:21:34AM +0800, Jinjiang Tu wrote:
>
> 在 2026/9/6 7:21, Andrew Morton 写道:
> > On Sat, 5 Sep 2026 14:18:19 +0800 Jinjiang Tu <tujinjiang@huawei.com> wrote:
> >
> > > On arm64 server, we found  __anon_vma_prepare() reuses anon_vma and
> > > anon_vma->root is stale due to missing memory barrier, leading to
> > > lock and unlock two different anon_vma->root, thus leading to a anon_vma
> > > will never be unlocked, and another anon_vma couldn't be locked anymore.
> > >
> > > The race is as follows:
> > >
> > > ...
> > >
> > > Without this fix, our production environment could reproduce this issue
> > > about 2-5 times each month.
> > That's important info.  Can you tell us more?  How was this observed by
> > operations people?  A copy-n-paste of the kernel messages would be helpful.
> >
> > This will help downstream people to decide whether this patch fixes a
> > thing they're seeing happen.
>
> We can see a task that tries to grab anon_vma lock triggers hungtask.
>
> [2434968.289510] INFO: task main:2354726 blocked for more than 120 seconds.
> [2434968.289516]       Tainted: G            E     5.10.0-0021.aarch64 #1
> [2434968.289517] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> [2434968.289519] task:main            state:D stack:    0 pid:2354726 ppid:2350673 flags:0x00000a01
> [2434968.289523] Call trace:
> [2434968.289531]  __switch_to+0x7c/0xbc
> [2434968.289540]  __schedule+0x3b4/0x8a0
> [2434968.289542]  schedule+0x50/0xe0
> [2434968.289545]  rwsem_down_write_slowpath+0x3cc/0x6cc
> [2434968.289547]  down_write+0x60/0x260
> [2434968.289551]  __anon_vma_prepare+0x6c/0x210
> [2434968.289555]  do_anonymous_page+0x258/0x660
> [2434968.289557]  handle_pte_fault+0x188/0x214
> [2434968.289559]  __handle_mm_fault+0x1b0/0x380
> [2434968.289561]  handle_mm_fault+0xf4/0x284
> [2434968.289563]  do_page_fault+0x19c/0x494
> [2434968.289565]  do_translation_fault+0xcc/0xf8
> [2434968.289569]  do_mem_abort+0x48/0xac
> [2434968.289570]  el0_da+0x44/0x80
> [2434968.289572]  el0_sync_handler+0x88/0xb4
> [2434968.289573]  el0_sync+0x160/0x180
>
> After analyzing the vmcore, we found the anon_vma->root->rwsem.count is -1,
> and there is another anon_vma whose anon_vma->root->rwsem.count is 1, and
> the anon_vma->root->rwsem.owner shows the lock is held, but the stack of
> the task shows the task doesn't hold the anon_vma lock.

Can we have these details in the commit message on respin please? Thanks :)

>
> >

--
Cheers, Lorenzo