Re: [PATCH] mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish
flat view
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Date: 2026-09-08 09:32:09
On Tue, Sep 08, 2026 at 10:48:29AM +0800, Jinjiang Tu wrote:
在 2026/9/7 21:52, Lorenzo Stoakes (ARM) 写道:
quoted hunk ↗ jump to hunk
quoted
quoted
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 :)
quoted
quoted
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