From: Andrew Morton <akpm@linux-foundation.org>
To: Jinjiang Tu <tujinjiang@huawei.com>
Cc: <david@kernel.org>, <ljs@kernel.org>, <riel@surriel.com>,
<liam@infradead.org>, <vbabka@kernel.org>, <harry@kernel.org>,
<jannh@google.com>, <lance.yang@linux.dev>,
<minchan.kim@gmail.com>, <lwoodman@redhat.com>,
<kamezawa.hiroyu@jp.fujitsu.com>, <mel@csn.ul.ie>,
<linux-mm@kvack.org>, <wangkefeng.wang@huawei.com>,
<sunnanyong@huawei.com>
Subject: Re: [PATCH] mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish
Date: Sat, 5 Sep 2026 16:21:28 -0700 [thread overview]
Message-ID: <20260905162128.46fe06ad3689af1db637a005@linux-foundation.org> (raw)
In-Reply-To: <20260905061820.642437-1-tujinjiang@huawei.com>
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.
next prev parent reply other threads:[~2026-09-05 23:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-05 6:18 [PATCH] mm/rmap: fix missing barrier between anon_vma init and vma->anon_vma publish Jinjiang Tu
2026-09-05 13:22 ` Rik van Riel
2026-09-07 1:13 ` Jinjiang Tu
2026-09-05 23:21 ` Andrew Morton [this message]
2026-09-07 2:21 ` Jinjiang Tu
2026-09-07 12:47 ` Lorenzo Stoakes (ARM)
2026-09-08 2:08 ` Jinjiang Tu
2026-09-08 10:36 ` Lorenzo Stoakes (ARM)
2026-09-07 12:43 ` Lance Yang
2026-09-08 2:07 ` Jinjiang Tu
2026-09-07 13:52 ` Lorenzo Stoakes (ARM)
2026-09-08 2:48 ` Jinjiang Tu
2026-09-08 9:31 ` Lorenzo Stoakes (ARM)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260905162128.46fe06ad3689af1db637a005@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=harry@kernel.org \
--cc=jannh@google.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=lwoodman@redhat.com \
--cc=mel@csn.ul.ie \
--cc=minchan.kim@gmail.com \
--cc=riel@surriel.com \
--cc=sunnanyong@huawei.com \
--cc=tujinjiang@huawei.com \
--cc=vbabka@kernel.org \
--cc=wangkefeng.wang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.