linux-kernel - Re: [PATCH v4 5/5] rust: devres: implement register

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aF-N-luMxFTurl91@Mac.home>
Date: Fri, 27 Jun 2025 23:38:50 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: Benno Lossin <lossin@...nel.org>
Cc: Danilo Krummrich <dakr@...nel.org>, gregkh@...uxfoundation.org,
	rafael@...nel.org, ojeda@...nel.org, alex.gaynor@...il.com,
	gary@...yguo.net, bjorn3_gh@...tonmail.com, a.hindborg@...nel.org,
	aliceryhl@...gle.com, tmgross@...ch.edu, david.m.ertman@...el.com,
	ira.weiny@...el.com, leon@...nel.org, kwilczynski@...nel.org,
	bhelgaas@...gle.com, rust-for-linux@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH v4 5/5] rust: devres: implement register_release()

On Sat, Jun 28, 2025 at 08:06:52AM +0200, Benno Lossin wrote:
> On Sat Jun 28, 2025 at 12:06 AM CEST, Boqun Feng wrote:
> > On Fri, Jun 27, 2025 at 01:19:53AM +0200, Benno Lossin wrote:
> >> On Thu Jun 26, 2025 at 10:48 PM CEST, Danilo Krummrich wrote:
> >> > On Thu, Jun 26, 2025 at 01:37:22PM -0700, Boqun Feng wrote:
> >> >> On Thu, Jun 26, 2025 at 10:00:43PM +0200, Danilo Krummrich wrote:
> >> >> > +/// [`Devres`]-releaseable resource.
> >> >> > +///
> >> >> > +/// Register an object implementing this trait with [`register_release`]. Its `release`
> >> >> > +/// function will be called once the device is being unbound.
> >> >> > +pub trait Release {
> >> >> > +    /// The [`ForeignOwnable`] pointer type consumed by [`register_release`].
> >> >> > +    type Ptr: ForeignOwnable;
> >> >> > +
> >> >> > +    /// Called once the [`Device`] given to [`register_release`] is unbound.
> >> >> > +    fn release(this: Self::Ptr);
> >> >> > +}
> >> >> > +
> >> >> 
> >> >> I would like to point out the limitation of this design, say you have a
> >> >> `Foo` that can ipml `Release`, with this, I think you could only support
> >> >> either `Arc<Foo>` or `KBox<Foo>`. You cannot support both as the input
> >> >> for `register_release()`. Maybe we want:
> >> >> 
> >> >>     pub trait Release<Ptr: ForeignOwnable> {
> >> >>         fn release(this: Ptr);
> >> >>     }
> >> >
> >> > Good catch! I think this wasn't possible without ForeignOwnable::Target.
> >> 
> >> Hmm do we really need that? Normally you either store a type in a shared
> >
> > I think it might be quite common, for example, `Foo` may be a general
> > watchdog for a subsystem, for one driver, there might be multiple
> > devices that could feed the dog, for another driver, there might be only
> > one. For the first case we need Arc<Watchdog> or the second we can do
> > Box<Watchdog>.
> 
> I guess then the original `&self` design is better? Not sure...
> 

This is what you said in v3:

"""
and then `register_release` is:

    pub fn register_release<T: Release>(dev: &Device<Bound>, data: T::Ptr) -> Result

This way, one can store a `Box<T>` and get access to the `T` at the end.
Or if they store the value in an `Arc<T>`, they have the option to clone
it and give it to somewhere else.
"""

I think that's the reason why we think the current version (the
associate type design) is better than `&self`?

The generic type design (i.e. Release<P: ForeignOwnable>) just further
allows this "different behaviors between Box and Arc" for the same type
T. I think it's a natural extension of the current design and provides
some better flexibility.

> > What's the downside?
> 
> You'll need to implement `Release` twice:
> 

Only if you need to support both for `Foo`, right? You can impl only one
if you only need one.

Also you can do:

    impl<P: ForeignOwnable<Target=Foo> + Deref<Target=Foo>> Release<P> for Foo {
        fn release(this: P) {
	    this.deref().do_sth();
	}
    }

if you want Box and Arc case share the similar behavior, right?

>     impl Release<Box<Self>> for Foo {
>         fn release(this: Box<Self>) {
>             /* ... */
>         }
>     }
> 
>     impl Release<Arc<Self>> for Foo {
>         fn release(this: Arc<Self>) {
>             /* ... */
>         }
>     }
> 
> This also means that you can have different behavior for `Box` and
> `Arc`...

That's the point, as one of the benefits you mentioned above for the
associate type design, just extending it to the same type.

Regards,
Boqun

> 
> ---
> Cheers,
> Benno