From: Danilo Krummrich <dakr@redhat.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: rafael@kernel.org, ojeda@kernel.org, alex.gaynor@gmail.com,
wedsonaf@gmail.com, boqun.feng@gmail.com, gary@garyguo.net,
bjorn3_gh@protonmail.com, benno.lossin@proton.me,
a.hindborg@samsung.com, aliceryhl@google.com, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
rust-for-linux@vger.kernel.org, x86@kernel.org, lyude@redhat.com,
pstanner@redhat.com, ajanulgu@redhat.com, airlied@redhat.com
Subject: Re: [PATCH 8/8] rust: add device::Data
Date: Tue, 26 Mar 2024 17:54:19 +0100 [thread overview]
Message-ID: <ZgL9u-L1T_J1UZLt@pollux> (raw)
In-Reply-To: <2024032509-tanned-calamity-4e1c@gregkh>
On Mon, Mar 25, 2024 at 07:21:04PM +0100, Greg KH wrote:
> On Mon, Mar 25, 2024 at 06:49:12PM +0100, Danilo Krummrich wrote:
> > From: Wedson Almeida Filho <wedsonaf@gmail.com>
> >
> > This allows access to registrations and io resources to be automatically
> > revoked when devices are removed, even if the ref count to their state
> > is non-zero.
>
> So it's re-implementing the devm_*() calls? Why?
It's not. Taking IO resources as an example it's more a generalization of what
e.g. DRM solves with drm_dev_unplug() and drm_dev_{enter,exit}().
While devm_*() ensures to, for instance, iounmap() a mapping when a device is
detached, the Revocable<> resource ensures that a driver can't access the
pointer pointing to the just unmapped memory anymore.
So, this isn't something that replaces devm_*(), but kinda builds on top of it.
For instance, we could call Revocable::revoke() from a devm_*() callback.
However, and that' what this patch currently does for simplicity, we could also
just call it from the corresponding driver's remove() callback.
>
> And this will trigger only on remove, but which remove? The bus remove?
> Or the unbinding of the driver to the device (two totally different
> things, be specific and very careful here.)
The above comment says "device remove", maybe say device / driver detach
instead?
>
> If this is implementing the devm_() calls, why not call them the same
> thing?
>
>
> >
> > Co-developed-by: Andreas Hindborg <a.hindborg@samsung.com>
> > Signed-off-by: Andreas Hindborg <a.hindborg@samsung.com>
> > Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com>
> > Signed-off-by: Danilo Krummrich <dakr@redhat.com>
> > ---
> > rust/kernel/device.rs | 120 +++++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 119 insertions(+), 1 deletion(-)
> >
> > diff --git a/rust/kernel/device.rs b/rust/kernel/device.rs
> > index 7309a236f512..707c699c3090 100644
> > --- a/rust/kernel/device.rs
> > +++ b/rust/kernel/device.rs
> > @@ -4,7 +4,22 @@
> > //!
> > //! C header: [`include/linux/device.h`](../../../../include/linux/device.h)
> >
> > -use crate::{bindings, str::CStr};
> > +use macros::pin_data;
> > +
> > +use crate::{
> > + bindings,
> > + error::Result,
> > + init::InPlaceInit,
> > + init::PinInit,
> > + pin_init,
> > + revocable::{Revocable, RevocableGuard},
> > + str::CStr,
> > + sync::{LockClassKey, RevocableMutex, UniqueArc},
> > +};
> > +use core::{
> > + ops::{Deref, DerefMut},
> > + pin::Pin,
> > +};
> >
> > /// A raw device.
> > ///
> > @@ -95,3 +110,106 @@ fn clone(&self) -> Self {
> > Self::from_dev(self)
> > }
> > }
> > +
> > +/// Device data.
> > +///
> > +/// When a device is removed (for whatever reason, for example, because the device was unplugged or
> > +/// because the user decided to unbind the driver), the driver is given a chance to clean its state
> > +/// up, and all io resources should ideally not be used anymore.
>
> Wait, unplugging a device and unbinding a device from a driver are two
> totally different things, do NOT get them mixed up or assume that they
> are the same thing at all please. They have different lifetime rules
> and different patterns of what happens.
I think the comment does not claim that device unplug and device / driver
unbind are the same thing. I rather think in this context the expection is that,
ultimately, both result into the fact that the corresponding device resources
are not available anymore and hence shouldn't be used anymore. Where the latter
is enforced by using Revocable<>.
>
> So this needs to be taken out and rewritten from the beginning please.
> If the comments describe something that is incorrect, I can't trust that
> the code is correct...
Not sure the comment is actually claiming something incorrect. If, with the
above explanation, you still think so, please let me know how to phrase it
correctly, such that I can improve this patch accordingly.
>
> thanks,
>
> greg k-h
>
next prev parent reply other threads:[~2024-03-26 16:54 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 17:49 [PATCH 0/8] [RFC] Rust device / driver abstractions Danilo Krummrich
2024-03-25 17:49 ` [PATCH 1/8] arch: x86: tools: increase symbol name size Danilo Krummrich
2024-03-25 17:53 ` Miguel Ojeda
2024-03-25 18:01 ` Danilo Krummrich
2024-03-25 18:18 ` Miguel Ojeda
2024-03-25 17:49 ` [PATCH 2/8] rust: device: Add a minimal RawDevice trait Danilo Krummrich
2024-03-25 18:14 ` Greg KH
2024-03-25 18:22 ` Miguel Ojeda
2024-03-26 22:38 ` Danilo Krummrich
2024-03-27 5:25 ` Greg KH
2024-03-27 11:39 ` Danilo Krummrich
2024-03-25 17:49 ` [PATCH 3/8] rust: device: Add a stub abstraction for devices Danilo Krummrich
2024-03-25 17:58 ` Boqun Feng
2024-03-27 11:36 ` Danilo Krummrich
2024-03-25 18:14 ` Greg KH
2024-03-25 18:17 ` Greg KH
2024-03-26 16:01 ` Danilo Krummrich
2024-03-26 18:03 ` Greg KH
2024-03-26 19:03 ` Boqun Feng
2024-03-26 21:01 ` Danilo Krummrich
2024-03-27 1:38 ` Wedson Almeida Filho
2024-03-27 5:22 ` Greg KH
2024-03-27 9:05 ` Philipp Stanner
2024-03-27 9:13 ` Greg KH
2024-03-27 11:35 ` Danilo Krummrich
2024-03-25 17:49 ` [PATCH 4/8] rust: add driver abstraction Danilo Krummrich
2024-03-25 18:12 ` Greg KH
2024-03-25 18:30 ` Greg KH
2024-03-25 19:36 ` David Airlie
2024-03-26 5:37 ` Greg KH
2024-03-26 6:02 ` David Airlie
2024-03-26 6:14 ` Greg KH
2024-03-26 6:34 ` David Airlie
2024-03-31 19:17 ` Fabien Parent
2024-04-02 13:51 ` Danilo Krummrich
2024-03-28 10:41 ` Viresh Kumar
2024-03-25 17:49 ` [PATCH 5/8] rust: add rcu abstraction Danilo Krummrich
2024-03-25 17:49 ` [PATCH 6/8] rust: add revocable mutex Danilo Krummrich
2024-03-25 18:22 ` Greg KH
2024-03-26 18:13 ` Danilo Krummrich
2024-03-26 18:17 ` Greg KH
2024-03-26 21:32 ` Danilo Krummrich
2024-03-25 17:49 ` [PATCH 7/8] rust: add revocable objects Danilo Krummrich
2024-03-25 18:21 ` Greg KH
2024-03-26 17:07 ` Danilo Krummrich
2024-03-26 18:16 ` Greg KH
2024-03-26 21:48 ` Danilo Krummrich
2024-03-27 1:31 ` Wedson Almeida Filho
2024-03-25 17:49 ` [PATCH 8/8] rust: add device::Data Danilo Krummrich
2024-03-25 18:21 ` Greg KH
2024-03-26 16:54 ` Danilo Krummrich [this message]
2024-03-26 18:12 ` Greg KH
2024-03-26 22:24 ` 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=ZgL9u-L1T_J1UZLt@pollux \
--to=dakr@redhat.com \
--cc=a.hindborg@samsung.com \
--cc=airlied@redhat.com \
--cc=ajanulgu@redhat.com \
--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=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=lyude@redhat.com \
--cc=mingo@redhat.com \
--cc=ojeda@kernel.org \
--cc=pstanner@redhat.com \
--cc=rafael@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=wedsonaf@gmail.com \
--cc=x86@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