From: Danilo Krummrich <dakr@kernel.org>
To: Benno Lossin <lossin@kernel.org>
Cc: gregkh@linuxfoundation.org, rafael@kernel.org, ojeda@kernel.org,
alex.gaynor@gmail.com, boqun.feng@gmail.com, gary@garyguo.net,
bjorn3_gh@protonmail.com, benno.lossin@proton.me,
a.hindborg@kernel.org, aliceryhl@google.com, tmgross@umich.edu,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] rust: devres: get rid of Devres' inner Arc
Date: Sun, 22 Jun 2025 14:08:38 +0200 [thread overview]
Message-ID: <aFfyRuYPxUfc7TM-@pollux> (raw)
In-Reply-To: <DASVDU1WY5RH.1VLCIQ4TIS0FP@kernel.org>
On Sun, Jun 22, 2025 at 09:05:51AM +0200, Benno Lossin wrote:
> On Thu Jun 12, 2025 at 4:51 PM CEST, Danilo Krummrich wrote:
> > +#[pin_data(PinnedDrop)]
> > +pub struct Devres<T> {
> > + dev: ARef<Device>,
> > + callback: unsafe extern "C" fn(*mut c_void),
>
> Do I remember correctly that we at some point talked about adding a
> comment here for why this is needed? (ie it's needed, because
> `Self::callback` might return different addresses?)
Correct -- thanks for reminding me of that. Will add the corresponding comment.
> > + #[pin]
> > + data: Revocable<T>,
> > + #[pin]
> > + devm: Completion,
> > + #[pin]
> > + revoke: Completion,
>
> Probably a good idea to add some doc comments explaining what these two
> completions track.
>
> (feel free to do these in another patch or in a follow-up)
No, I think it'd be good to do it right away -- will add them.
> > +#[pinned_drop]
> > +impl<T> PinnedDrop for Devres<T> {
> > + fn drop(self: Pin<&mut Self>) {
> > // SAFETY: When `drop` runs, it is guaranteed that nobody is accessing the revocable data
> > // anymore, hence it is safe not to wait for the grace period to finish.
> > - if unsafe { self.0.data.revoke_nosync() } {
> > - // We revoked `self.0.data` before the devres action did, hence try to remove it.
> > - if !DevresInner::remove_action(&self.0) {
> > + if unsafe { self.data.revoke_nosync() } {
> > + // We revoked `self.data` before the devres action did, hence try to remove it.
> > + if !self.remove_action() {
> > // We could not remove the devres action, which means that it now runs concurrently,
> > - // hence signal that `self.0.data` has been revoked successfully.
> > - self.0.revoke.complete_all();
> > + // hence signal that `self.data` has been revoked by us successfully.
> > + self.revoke.complete_all();
> > +
> > + // Wait for `Self::devres_callback` to be done using this object.
> > + self.devm.wait_for_completion();
> > }
> > + } else {
> > + // `Self::devres_callback` revokes `self.data` for us, hence wait for it to be done
> > + // using this object.
> > + self.devm.wait_for_completion();
>
> I don't understand this change, maybe it's best to move that into a
> separate commit?
We can't do that, without this change the code would be incorrect.
What happens here is that, if drop() races with devres_callback() we have to
make drop() wait until devres_callback() is completed, because otherwise
devres_callback() might experience a use-after-free.
Previoulsly this has been taken care of by Arc<DevresInner>, which C devres held
a reference of.
next prev parent reply other threads:[~2025-06-22 12:08 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-12 14:51 [PATCH 0/4] Improvements for Devres Danilo Krummrich
2025-06-12 14:51 ` [PATCH 1/4] rust: revocable: support fallible PinInit types Danilo Krummrich
2025-06-12 15:48 ` Benno Lossin
2025-06-12 15:58 ` Danilo Krummrich
2025-06-12 16:17 ` Benno Lossin
2025-06-12 16:20 ` Danilo Krummrich
2025-06-12 14:51 ` [PATCH 2/4] rust: devres: replace Devres::new_foreign_owned() Danilo Krummrich
2025-06-13 3:14 ` Viresh Kumar
2025-06-21 21:10 ` Benno Lossin
2025-06-21 21:45 ` Danilo Krummrich
2025-06-22 7:42 ` Benno Lossin
2025-06-22 9:55 ` Danilo Krummrich
2025-06-22 20:18 ` Benno Lossin
2025-06-12 14:51 ` [PATCH 3/4] rust: devres: get rid of Devres' inner Arc Danilo Krummrich
2025-06-22 7:05 ` Benno Lossin
2025-06-22 12:08 ` Danilo Krummrich [this message]
2025-06-22 20:16 ` Benno Lossin
2025-06-22 15:45 ` Danilo Krummrich
2025-06-22 20:15 ` Benno Lossin
2025-06-12 14:51 ` [PATCH 4/4] rust: devres: implement register_foreign_release() Danilo Krummrich
2025-06-22 7:26 ` Benno Lossin
2025-06-22 12:46 ` Danilo Krummrich
2025-06-22 20:14 ` Benno Lossin
2025-06-22 20:25 ` Danilo Krummrich
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=aFfyRuYPxUfc7TM-@pollux \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
/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.