From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: paulmck@kernel.org
Cc: Jonas Oberhauser <jonas.oberhauser@huawei.com>,
Jonas Oberhauser <jonas.oberhauser@huaweicloud.com>,
Boqun Feng <boqun.feng@gmail.com>,
"lkmm@lists.linux.dev" <lkmm@lists.linux.dev>,
Olivier Dion <odion@efficios.com>
Subject: Re: [RFC PATCH 1/1] hpref: Hazard Pointers with Reference Counter
Date: Wed, 7 Jan 2026 15:04:11 -0500 [thread overview]
Message-ID: <2e8b6065-cbbd-441b-b888-1eea26f716b7@efficios.com> (raw)
In-Reply-To: <c284bd91-c27a-4e12-8d7d-82def9798fc8@paulmck-laptop>
On 2026-01-07 12:48, Paul E. McKenney wrote:
> On Wed, Jan 07, 2026 at 09:40:56AM -0500, Mathieu Desnoyers wrote:
[...]
>
>> * RCU grace period guarantee:
>>
>> For the read-side critical section (rcu_read_{lock,unlock}) pairing with
>> synchronize_rcu, we've updated the liburcu read lock/unlock
>> implementation to use either atomic thread fence as full barrier or
>> SEQ_CST stores. We've also introduced a urcu/annotate.h header to help
>> annotating memory access groups. This helps threadsanitizer track the
>> dependency ordering inherent to RCU grace periods.
>
> The atomic thread fence is for threadsanitizer's benefit? In the MB
> rcu_read_lock() and rcu_read_unlock() case, is barrier() or a light-weight
> asymmetric fence still used?
For urcu-memb and urcu-bp, we use a lightweight compiler cmm_barrier()
in rcu_read_{lock,unlock}() paired with membarrier(2) within
synchronize_rcu() when membarrier is available, else we fallback
on cmm_smp_mb() everywhere.
For urcu-mb and urcu-qsbr, we previously (before 0.15) had the more
heavyweight cmm_smp_mb(). When compiling with the atomic builtins
configure flag, this just maps to atomic thread fence. AFAIK
TSAN does not model atomic thread fence, so we need to rely on
explicit TSAN annotations of happens-before relationships of
relaxed memory accesses ordered by atomic thread fence (or
barrier+membarrier pairing trick) in those scenarios.
Now that I review the urcu-mb and urcu-qsbr 0.15 code again, I suspect
we're missing ordering between the seq-cst store to rcu_reader.ctr
and relaxed load of the futex state. I have prepared the following
commits to address this:
https://review.lttng.org/c/userspace-rcu/+/16151 urcu-mb: Use CMM_SEQ_CST_FENCE for _urcu_mb_read_unlock_update_and_wakeup
https://review.lttng.org/c/userspace-rcu/+/16152 urcu-qsbr: Use CMM_SEQ_CST_FENCE for quiescent state update and offline
We're also missing a TSAN acquire annotation for the urcu_mb_gp.ctr load
in _urcu_mb_read_lock_update. This is only relevant for TSAN analyses:
https://review.lttng.org/c/userspace-rcu/+/16156 urcu-mb: Add missing TSAN annotation to _urcu_mb_read_lock_update
And for the sake of combining the store+cmm_smp_mb() pattern into
a CMM_SEQ_CST_FENCE which can be optimized by architectures,
the following commits:
https://review.lttng.org/c/userspace-rcu/+/16153 urcu-mb: Use CMM_SEQ_CST_FENCE for _urcu_mb_read_lock_update
https://review.lttng.org/c/userspace-rcu/+/16154 urcu-qsbr: Use CMM_SEQ_CST_FENCE for _urcu_qsbr_thread_online
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
prev parent reply other threads:[~2026-01-07 20:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-21 16:42 [RFC PATCH 1/1] hpref: Hazard Pointers with Reference Counter Mathieu Desnoyers
2024-09-21 21:07 ` Lai Jiangshan
2024-09-22 7:47 ` Mathieu Desnoyers
2024-09-25 5:57 ` Jonas Oberhauser
2024-09-25 6:35 ` Mathieu Desnoyers
2024-09-25 10:06 ` Jonas Oberhauser
2024-09-25 11:36 ` Mathieu Desnoyers
2024-09-25 12:02 ` Jonas Oberhauser
2024-09-28 11:22 ` Jonas Oberhauser
2024-09-28 11:33 ` Mathieu Desnoyers
2024-09-28 11:50 ` Jonas Oberhauser
2024-09-30 13:31 ` Jonas Oberhauser
2024-10-01 15:24 ` Paul E. McKenney
2026-01-06 14:52 ` Mathieu Desnoyers
2026-01-07 9:38 ` Jonas Oberhauser
2026-01-07 14:40 ` Mathieu Desnoyers
2026-01-07 17:48 ` Paul E. McKenney
2026-01-07 20:04 ` Mathieu Desnoyers [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=2e8b6065-cbbd-441b-b888-1eea26f716b7@efficios.com \
--to=mathieu.desnoyers@efficios.com \
--cc=boqun.feng@gmail.com \
--cc=jonas.oberhauser@huawei.com \
--cc=jonas.oberhauser@huaweicloud.com \
--cc=lkmm@lists.linux.dev \
--cc=odion@efficios.com \
--cc=paulmck@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).