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

[Jinjiang Tu <tujinjiang@huawei.com>]

在 2026/9/9 23:25, Jann Horn 写道:
> On Tue, Sep 8, 2026 at 2:57 PM Jinjiang Tu <tujinjiang@huawei.com> wrote:
>> diff --git a/mm/rmap.c b/mm/rmap.c
>> index d1819fd69938..f3b21aaa34ee 100644
>> --- a/mm/rmap.c
>> +++ b/mm/rmap.c
>> @@ -209,7 +209,11 @@ int __anon_vma_prepare(struct vm_area_struct *vma)
>>          /* page_table_lock to protect against threads */
>>          spin_lock(&mm->page_table_lock);
>>          if (likely(!vma->anon_vma)) {
>> -               vma->anon_vma = anon_vma;
>> +               /*
>> +                * Make anon_vma fields visible before anon_vma is published.
>> +                * Paired with an address dependency in reusable_anon_vma().
>> +                */
>> +               smp_store_release(&vma->anon_vma, anon_vma);
> Yes, this should go in. There are remaining theoretical issues (we
> really should also be using READ_ONCE() in places like unuse_mm(), see
> <https://lore.kernel.org/all/20230726214103.3261108-4-jannh@google.com/>),
> but this is the important fix.

Theoretically yes, but I'm curious whether these are actual problems in practice.

In hugepage_vma_revalidate() and unuse_mm(), the code only checks whether anon_vma
is non-NULL — it doesn't dereference anon_vma to access its fields.

In KSM, rmap_item->anon_vma is assigned from vma->anon_vma, and the rmap_item is
then inserted into a stable node. There is a very long time window before
rmap_walk_ksm() could ever observe it.

>