From: "Benno Lossin" <lossin@kernel.org>
To: "Danilo Krummrich" <dakr@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 11:01:58 +0200 [thread overview]
Message-ID: <DAX6ZGG442EA.2C365WV15IC7C@kernel.org> (raw)
In-Reply-To: <aF3dlfLiy8w4henN@pollux>
On Fri Jun 27, 2025 at 1:53 AM CEST, Danilo Krummrich wrote:
> 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.
Ahh, planning ahead :)
How would you have shared it if you didn't do the devres rework? Or is
this one of the reasons to do that?
>> > 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.
Makes sense, I don't have too much data on where to place the error,
since I only have had rather simple uses of pin-init. So you could have
a case where it makes sense to put the error outside of the initializer.
>> > /// # 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.
Ahh right, I thought I was missing something! This also should be
mentioned in the safety comment though! Feel free to do it in some later
patch or create a good-first-issue :)
---
Cheers,
Benno
next prev parent reply other threads:[~2025-06-27 9:02 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
2025-06-27 9:01 ` Benno Lossin [this message]
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=DAX6ZGG442EA.2C365WV15IC7C@kernel.org \
--to=lossin@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=dakr@kernel.org \
--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=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.