Re: [PATCH] mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish
From: Jinjiang Tu <hidden>
Date: 2026-09-07 02:21:47
在 2026/9/6 7:21, Andrew Morton 写道:
On Sat, 5 Sep 2026 14:18:19 +0800 Jinjiang Tu [off-list ref] wrote:quoted
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.