From: Waiman Long <llong@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>, pengyu <pengyu@kylinos.cn>
Cc: mingo@redhat.com, will@kernel.org, boqun.feng@gmail.com,
linux-kernel@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>,
t.haas@tu-bs.de, parri.andrea@gmail.com, j.alglave@ucl.ac.uk,
luc.maranget@inria.fr, paulmck@kernel.org,
jonas.oberhauser@huaweicloud.com, r.maseli@tu-bs.de,
lkmm@lists.linux.dev, stern@rowland.harvard.edu
Subject: Re: [PATCH] locking/qspinlock: use xchg with _mb in slowpath for arm64
Date: Tue, 16 Sep 2025 12:58:54 -0400 [thread overview]
Message-ID: <f971b01a-2d76-4511-8880-0f4de2a042d9@redhat.com> (raw)
In-Reply-To: <20250916141032.GJ3245006@noisy.programming.kicks-ass.net>
On 9/16/25 10:10 AM, Peter Zijlstra wrote:
> On Tue, Sep 16, 2025 at 11:39:03AM +0800, pengyu wrote:
>> From: Yu Peng <pengyu@kylinos.cn>
>>
>> A hardlock detected on arm64: rq->lock was released, but a CPU
>> blocked at mcs_node->locked and timed out.
>>
>> We found xchg_tail and atomic_try_cmpxchg_relaxed used _relaxed
>> versions without memory barriers. Suspected insufficient coherence
>> guarantees on some arm64 microarchitectures, potentially leading to
>> the following issues occurred:
>>
>> CPU0: CPU1:
>> // Set tail to CPU0
>> old = xchg_tail(lock, tail);
>>
>> //CPU0 read tail is itself
>> if ((val & _Q_TAIL_MASK) == tail)
>> // CPU1 exchanges the tail
>> old = xchg_tail(lock, tail)
>> //assuming CPU0 not see tail change
>> atomic_try_cmpxchg_relaxed(
>> &lock->val, &val, _Q_LOCKED_VAL)
>> //released without notifying CPU1
>> goto release;
>> //hardlock detected
>> arch_mcs_spin_lock_contended(
>> &node->locked)
>>
>> Therefore, xchg_tail and atomic_try_cmpxchg using _mb to replace _relaxed.
> Yeah, no. We do not apply patches based on suspicion. And we most
> certainly do not sprinkle #ifdef ARM64 in generic code.
>
> There is this thread:
>
> https://lkml.kernel.org/r/cb83e3e4-9e22-4457-bf61-5614cc4396ad@tu-bs.de
Ah, I was not cc'ed on this email thread. That is why I was not aware of
this discussion about xchg_tail(). It is an interesting read.
Anyway, this particular problem may be about the clarity of the arm64
memory model and whether any microarch's strictly follow it or not.
Cheers,
Longman
prev parent reply other threads:[~2025-09-16 16:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20250916033903.3374794-1-pengyu@kylinos.cn>
2025-09-16 14:10 ` [PATCH] locking/qspinlock: use xchg with _mb in slowpath for arm64 Peter Zijlstra
2025-09-16 16:00 ` Will Deacon
2025-09-17 10:51 ` pengyu
2025-09-17 11:37 ` Will Deacon
2025-09-19 10:22 ` pengyu
2025-09-16 16:58 ` Waiman Long [this message]
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=f971b01a-2d76-4511-8880-0f4de2a042d9@redhat.com \
--to=llong@redhat.com \
--cc=boqun.feng@gmail.com \
--cc=j.alglave@ucl.ac.uk \
--cc=jonas.oberhauser@huaweicloud.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkmm@lists.linux.dev \
--cc=luc.maranget@inria.fr \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=parri.andrea@gmail.com \
--cc=paulmck@kernel.org \
--cc=pengyu@kylinos.cn \
--cc=peterz@infradead.org \
--cc=r.maseli@tu-bs.de \
--cc=stern@rowland.harvard.edu \
--cc=t.haas@tu-bs.de \
--cc=will@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).