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, a.hindborg@kernel.org,
aliceryhl@google.com, tmgross@umich.edu,
david.m.ertman@intel.com, ira.weiny@intel.com, leon@kernel.org,
kwilczynski@kernel.org, bhelgaas@google.com,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org
Subject: Re: [PATCH v4 3/5] rust: devres: get rid of Devres' inner Arc
Date: Fri, 27 Jun 2025 01:53:57 +0200 [thread overview]
Message-ID: <aF3dlfLiy8w4henN@pollux> (raw)
In-Reply-To: <DAWUWCQCW7WD.29U1POJFXTLXS@kernel.org>
On Fri, Jun 27, 2025 at 01:33:41AM +0200, Benno Lossin wrote:
> On Thu Jun 26, 2025 at 10:00 PM CEST, Danilo Krummrich wrote:
> > diff --git a/drivers/gpu/nova-core/gpu.rs b/drivers/gpu/nova-core/gpu.rs
> > index 60b86f370284..47653c14838b 100644
> > --- a/drivers/gpu/nova-core/gpu.rs
> > +++ b/drivers/gpu/nova-core/gpu.rs
>
> > @@ -161,14 +161,14 @@ fn new(bar: &Bar0) -> Result<Spec> {
> > pub(crate) struct Gpu {
> > spec: Spec,
> > /// MMIO mapping of PCI BAR 0
> > - bar: Devres<Bar0>,
> > + bar: Arc<Devres<Bar0>>,
>
> Can't you store it inline, given that you return an `impl PinInit<Self>`
> below?
I could, but I already know that we'll have to share bar later on.
> > fw: Firmware,
> > }
> >
> > impl Gpu {
> > pub(crate) fn new(
> > pdev: &pci::Device<device::Bound>,
> > - devres_bar: Devres<Bar0>,
> > + devres_bar: Arc<Devres<Bar0>>,
> > ) -> Result<impl PinInit<Self>> {
>
> While I see this code, is it really necessary to return `Result`
> wrapping the initializer here? I think it's probably better to return
> `impl PinInit<Self, Error>` instead. (of course in a different patch/an
> issue)
I will double check, but it's rather unlikely it makes sense. There's a lot of
initialization going on in Gpu::new(), the try_pin_init! call would probably get
too crazy.
>
> > let bar = devres_bar.access(pdev.as_ref())?;
> > let spec = Spec::new(bar)?;
>
> > @@ -44,6 +49,10 @@ struct DevresInner<T: Send> {
> > /// [`Devres`] users should make sure to simply free the corresponding backing resource in `T`'s
> > /// [`Drop`] implementation.
> > ///
> > +/// # Invariants
> > +///
> > +/// [`Self::inner`] is guaranteed to be initialized and is always accessed read-only.
> > +///
>
> Let's put this section below the examples, I really ought to write the
> safety docs one day and let everyone vote on this kind of stuff...
Sure!
> > /// # Example
> > ///
> > /// ```no_run
>
> > @@ -213,44 +233,63 @@ pub fn new(dev: &Device<Bound>, data: T, flags: Flags) -> Result<Self> {
> > /// }
> > /// ```
> > pub fn access<'a>(&'a self, dev: &'a Device<Bound>) -> Result<&'a T> {
> > - if self.0.dev.as_raw() != dev.as_raw() {
> > + if self.dev.as_raw() != dev.as_raw() {
> > return Err(EINVAL);
> > }
> >
> > // SAFETY: `dev` being the same device as the device this `Devres` has been created for
> > - // proves that `self.0.data` hasn't been revoked and is guaranteed to not be revoked as
> > - // long as `dev` lives; `dev` lives at least as long as `self`.
> > - Ok(unsafe { self.0.data.access() })
> > + // proves that `self.data` hasn't been revoked and is guaranteed to not be revoked as long
> > + // as `dev` lives; `dev` lives at least as long as `self`.
>
> What if the device has been unbound and a new device has been allocated
> in the exact same memory?
Unbound doesn't mean freed. Devres holds a reference of the device is was
created with, so it is impossible that it has been freed.
next prev parent reply other threads:[~2025-06-26 23:54 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-26 20:00 [PATCH v4 0/5] Improvements for Devres Danilo Krummrich
2025-06-26 20:00 ` [PATCH v4 1/5] rust: revocable: support fallible PinInit types Danilo Krummrich
2025-06-26 20:00 ` [PATCH v4 2/5] rust: devres: replace Devres::new_foreign_owned() Danilo Krummrich
2025-06-26 20:00 ` [PATCH v4 3/5] rust: devres: get rid of Devres' inner Arc Danilo Krummrich
2025-06-26 20:14 ` Boqun Feng
2025-06-26 23:33 ` Benno Lossin
2025-06-26 23:53 ` Danilo Krummrich [this message]
2025-06-27 9:01 ` Benno Lossin
2025-06-27 19:59 ` Benno Lossin
2025-06-26 20:00 ` [PATCH v4 4/5] rust: types: ForeignOwnable: Add type Target Danilo Krummrich
2025-06-26 20:20 ` Boqun Feng
2025-06-26 23:17 ` Benno Lossin
2025-06-26 23:21 ` Boqun Feng
2025-06-26 23:36 ` Benno Lossin
2025-06-26 23:45 ` Boqun Feng
2025-06-26 23:55 ` Boqun Feng
2025-06-27 9:05 ` Benno Lossin
2025-06-26 23:22 ` Benno Lossin
2025-06-27 19:53 ` Miguel Ojeda
2025-07-01 11:49 ` Alice Ryhl
2025-06-26 20:00 ` [PATCH v4 5/5] rust: devres: implement register_release() Danilo Krummrich
2025-06-26 20:37 ` Boqun Feng
2025-06-26 20:48 ` Danilo Krummrich
2025-06-26 21:16 ` Boqun Feng
2025-06-26 21:20 ` Danilo Krummrich
2025-06-26 21:21 ` Boqun Feng
2025-06-26 23:19 ` Benno Lossin
2025-06-27 22:06 ` Boqun Feng
2025-06-28 6:06 ` Benno Lossin
2025-06-28 6:38 ` Boqun Feng
2025-06-28 7:53 ` Benno Lossin
2025-06-28 9:58 ` Danilo Krummrich
2025-06-28 12:13 ` Benno Lossin
2025-06-28 12:32 ` Danilo Krummrich
2025-06-29 15:11 ` [PATCH v4 0/5] Improvements for Devres 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=aF3dlfLiy8w4henN@pollux \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=david.m.ertman@intel.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=ira.weiny@intel.com \
--cc=kwilczynski@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@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.