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

[Jinjiang Tu <tujinjiang@huawei.com>]

在 2026/9/7 20:47, Lorenzo Stoakes (ARM) 写道:
> 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 :)

Will update it in v2. Thanks.

>
> --
> Cheers, Lorenzo