From: Boqun Feng <boqun@kernel.org>
To: Gary Guo <gary@garyguo.net>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
"Paul E . McKenney" <paulmck@kernel.org>,
linux-kernel@vger.kernel.org,
Bradley Morgan <brads@mainlining.org>,
rcu@vger.kernel.org, lkmm@lists.linux.dev
Subject: Re: [PATCH hazptr 4/4] hazptr: Introduce "try acquire" fast path, fallback to overflow list
Date: Mon, 28 Sep 2026 17:32:11 +0200 [thread overview]
Message-ID: <arqIe2d8Koj857Kt@MacBook-0RXW5> (raw)
In-Reply-To: <DLQX09XGAHDL.1LSFQH13SU7XR@garyguo.net>
On Mon, Sep 28, 2026 at 12:32:34PM +0100, Gary Guo wrote:
[...]
> >> For some context, the current Rust revocable implementation uses RCU, but this
> >> is limiting the case where it can be used. The current C revocable series in
> >> https://lore.kernel.org/all/20260912123529.7951-1-tzungbi@kernel.org/ uses SRCU.
> >>
> >> I think this use case is a good one for hazptr, in fact, I have encouraged Alvin
> >> Sun to try it out and you can see an implementation (Rust) in here:
> >> https://lore.kernel.org/rust-for-linux/20260326-b4-tyr-debugfs-v1-6-074badd18716@linux.dev/
> >> Although, over the course of the year, we have been reducing the amount of
> >> revocable usage and shifting to represent things with lifetime..
> >>
> >
> > Paul asked me for the Rust usage a few days ago, and since we moved to
> > a lifetime based approach [1], which is better IMO, I don't think
> > switching to hazptr will should observable difference here, especially
> > for a real workload improvement. It's still worth trying to see how
> > hazptr in Rust would work for this, but it's less a sufficient condition
> > to merge hazptr from my understanding. Of course I could be wrong.
> >
> > [1]: https://lore.kernel.org/rust-for-linux/20260517000149.3226762-1-dakr@kernel.org/
>
> What we get rid of is to use `Revocable` (or `DevRes`) to protect resources
> where we _know_ that the resource is alive (for example, in device private data,
> because it's teared down by driver-core on unbind).
>
> However, there are cases where we can still have the `Revocable` pattern, for
> example when a class device is exposed to userspace and the bus device is
> unbinding. This is a pretty recurring pattern too, and cannot be handled via
> lifetime alone. This is what motivates the C revocable series.
>
Not trying to discourage switching to hazptr in `Revocable`, but I think
the only shortcoming of RCU there is "unable to sleep while referencing
a `Revocable`", right? Certainly hazptr can help on that but so does
SRCU. I'm unsure hazptr can show observable advantages against SRCU
here. But I could be wrong.
Regards,
Boqun
> Best,
> Gary
next prev parent reply other threads:[~2026-09-28 15:32 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-27 15:51 [PATCH hazptr 0/4] Hazard pointer updates Mathieu Desnoyers
2026-09-27 15:51 ` [PATCH hazptr 1/4] hazptr: Fix two-phase hazptr_synchronize race with detach Mathieu Desnoyers
2026-09-27 15:51 ` [PATCH hazptr 2/4] compiler.h: Introduce ptr_eq() to preserve address dependency Mathieu Desnoyers
2026-09-29 14:47 ` Linus Torvalds
2026-09-29 15:04 ` Mathieu Desnoyers
2026-09-29 15:16 ` Linus Torvalds
2026-09-29 15:42 ` Mathieu Desnoyers
2026-09-29 16:22 ` Gary Guo
2026-09-27 15:51 ` [PATCH hazptr 3/4] Documentation: RCU: Refer to ptr_eq() Mathieu Desnoyers
2026-09-27 15:51 ` [PATCH hazptr 4/4] hazptr: Introduce "try acquire" fast path, fallback to overflow list Mathieu Desnoyers
2026-09-27 16:40 ` Boqun Feng
2026-09-27 17:15 ` Mathieu Desnoyers
2026-09-27 17:24 ` Boqun Feng
2026-09-27 17:36 ` Mathieu Desnoyers
2026-09-27 18:16 ` Boqun Feng
2026-09-30 16:53 ` Paul E. McKenney
2026-09-27 17:26 ` Boqun Feng
2026-09-27 22:39 ` Gary Guo
2026-09-28 9:12 ` Boqun Feng
2026-09-28 11:32 ` Gary Guo
2026-09-28 14:56 ` Bradley Morgan
2026-09-28 15:32 ` Boqun Feng [this message]
2026-09-30 16:55 ` Paul E. McKenney
2026-09-28 9:27 ` Kunwu Chan
2026-10-06 8:01 ` Gary Guo
2026-09-27 16:07 ` [PATCH hazptr 0/4] Hazard pointer updates Bradley Morgan
2026-09-27 16:27 ` Mathieu Desnoyers
2026-09-27 16:33 ` Bradley Morgan
2026-09-27 16:45 ` Mathieu Desnoyers
2026-09-30 17:01 ` Paul E. McKenney
2026-09-27 16:15 ` Boqun Feng
2026-09-27 16:20 ` Mathieu Desnoyers
2026-09-27 16:22 ` Bradley Morgan
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=arqIe2d8Koj857Kt@MacBook-0RXW5 \
--to=boqun@kernel.org \
--cc=brads@mainlining.org \
--cc=gary@garyguo.net \
--cc=linux-kernel@vger.kernel.org \
--cc=lkmm@lists.linux.dev \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@kernel.org \
--cc=rcu@vger.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 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.