Re: [PATCH 5/7] rust: miscdevice: properly support device drivers

["Benno Lossin" <lossin@kernel.org>]

On Sat May 31, 2025 at 12:17 AM CEST, Danilo Krummrich wrote:
> On Fri, May 30, 2025 at 10:06:55PM +0200, Benno Lossin wrote:
>> On Fri May 30, 2025 at 4:24 PM CEST, Danilo Krummrich wrote:
>> > @@ -40,44 +41,43 @@ pub const fn into_raw<T: MiscDevice>(self) -> bindings::miscdevice {
>> >      }
>> >  }
>> >  
>> > -/// A registration of a miscdevice.
>> > -///
>> >  /// # Invariants
>> >  ///
>> > -/// `inner` is a registered misc device.
>> > +/// - `inner` is a registered misc device,
>> > +/// - `data` is valid for the entire lifetime of `Self`.
>> >  #[repr(C)]
>> >  #[pin_data(PinnedDrop)]
>> > -pub struct MiscDeviceRegistration<T: MiscDevice> {
>> > +struct RawDeviceRegistration<T: MiscDevice> {
>> >      #[pin]
>> >      inner: Opaque<bindings::miscdevice>,
>> > -    #[pin]
>> > -    data: Opaque<T::RegistrationData>,
>> > +    data: NonNull<T::RegistrationData>,
>> >      _t: PhantomData<T>,
>> 
>> You shouldn't need the `PhantomData` here.
>> 
>> Also, do we need to ask for `T: MiscDevice` here? Could we instead have
>> just `T` and then below you write
>> `RawDeviceRegistration<T::RegistrationData>` instead? (`new` of course
>> needs to have a new generic: `U: MiscDevice<RegistrationData = T>`)
>
> Sure, is there any advantage? Your proposal seems more complicated at a first
> glance.

It would make `RawDeviceRegistration` simpler, but maybe it's not worth
it.

>> >  }
>> >  
>> > -// SAFETY:
>> > -// - It is allowed to call `misc_deregister` on a different thread from where you called
>> > -//   `misc_register`.
>> > -// - Only implements `Send` if `MiscDevice::RegistrationData` is also `Send`.
>> > -unsafe impl<T: MiscDevice> Send for MiscDeviceRegistration<T> where T::RegistrationData: Send {}
>> > -
>> > -// SAFETY:
>> > -// - All `&self` methods on this type are written to ensure that it is safe to call them in
>> > -//   parallel.
>> > -// - `MiscDevice::RegistrationData` is always `Sync`.
>> > -unsafe impl<T: MiscDevice> Sync for MiscDeviceRegistration<T> {}
>> > -
>> > -impl<T: MiscDevice> MiscDeviceRegistration<T> {
>> > -    /// Register a misc device.
>> > -    pub fn register(
>> > +impl<T: MiscDevice> RawDeviceRegistration<T> {
>> > +    fn new<'a>(
>> >          opts: MiscDeviceOptions,
>> > -        data: impl PinInit<T::RegistrationData, Error>,
>> > -    ) -> impl PinInit<Self, Error> {
>> > +        parent: Option<&'a Device<Bound>>,
>> > +        data: &'a T::RegistrationData,
>> > +    ) -> impl PinInit<Self, Error> + 'a
>> > +    where
>> > +        T: 'a,
>> > +    {
>> >          try_pin_init!(Self {
>> > -            data <- Opaque::pin_init(data),
>> > +            // INVARIANT: `Self` is always embedded in a `MiscDeviceRegistration<T>`, hence `data`
>> > +            // is guaranteed to be valid for the entire lifetime of `Self`.
>> > +            data: NonNull::from(data),
>> 
>> Both the argument in the INVARIANT comment and way this works are a bit
>> flawed.
>
> Why is the argument flawed? Let's say we go with your proposal below, what would
> the safety requirement for RawDeviceRegistration::new and the invariant of
> RawDeviceRegistration look like? Wouldn't it be the exact same argument?

So what I write below it not really true. But the argument relies on the
fact that `data` is pointing to a value that will stay alive for the
duration of the existence of `self`. That should be a safety requirement
of `new` (even if we take a reference as an argument).

>> Instead, I'd recommend directly taking the `NonNull` as a
>> parameter. Yes the function will need to be `unsafe`, but the lifetime
>> that you're creating below only lives for `'a`, but the object might
>> live much longer. You might still be fine, but I'd just recommend
>> staying in raw pointer land (or in this case `NonNull`).

>> > @@ -108,6 +108,108 @@ pub fn device(&self) -> &Device {
>> >          unsafe { Device::as_ref((*self.as_raw()).this_device) }
>> >      }
>> >  
>> > +    fn data(&self) -> &T::RegistrationData {
>> > +        // SAFETY: The type invariant guarantees that `data` is valid for the entire lifetime of
>> > +        // `Self`.
>> > +        unsafe { self.data.as_ref() }
>> > +    }
>> > +}
>> > +
>> > +#[pinned_drop]
>> > +impl<T: MiscDevice> PinnedDrop for RawDeviceRegistration<T> {
>> > +    fn drop(self: Pin<&mut Self>) {
>> > +        // SAFETY: We know that the device is registered by the type invariants.
>> > +        unsafe { bindings::misc_deregister(self.inner.get()) };
>> > +    }
>> > +}
>> > +
>> > +#[expect(dead_code)]
>> > +enum DeviceRegistrationInner<T: MiscDevice> {
>> > +    Raw(Pin<KBox<RawDeviceRegistration<T>>>),
>> > +    Managed(Devres<RawDeviceRegistration<T>>),
>> 
>> These two names could be shortened (`DeviceRegistrationInner` and
>> `RawDeviceRegistration`) as they are only implementation details of this
>> file. How about `InnerRegistration` and `RawRegistration`? Or maybe
>> something even shorter.
>
> There's a reason why I keep them something with "DeviceRegistration" everywhere,
> which is to make it clear that it's both a device instance *and* a registration,
> which is actually rather uncommon and caused by the fact that device creation
> and registration needs to be done under the misc_mtx in misc_register().
>
> This is also the reason for those data structures to be a bit complicated; it
> would be much simpler if device creation and registration would be independent
> things.

Then keep the longer names.

>> > +}
>> > +
>> > +/// A registration of a miscdevice.
>> > +#[pin_data(PinnedDrop)]
>> > +pub struct MiscDeviceRegistration<T: MiscDevice> {
>> > +    inner: DeviceRegistrationInner<T>,
>> > +    #[pin]
>> > +    data: Opaque<T::RegistrationData>,
>> 
>> Why is it necessary to store `data` inside of `Opaque`?
>
> It was UnsafePinned before, but Alice proposed to go with Opaque for the
> meantime. Anyways, this is not introduced by this patch, it comes from
> Christians patch adding T::RegistrationData.

Ah then I'll re-read that discussion.

>> > +    this_device: ARef<Device>,
>> > +    _t: PhantomData<T>,
>> > +}

>> > +            inner: {
>> > +                // SAFETY:
>> > +                //   - `this` is a valid pointer to `Self`,
>> > +                //   - `data` was properly initialized above.
>> > +                let data = unsafe { &*(*this.as_ptr()).data.get() };
>> 
>> As mentioned above, this creates a reference that is valid for this
>> *block*. So its lifetime will end after the `},` and before
>> `this_device` is initialized.
>> 
>> It *might* be ok to turn it back into a raw pointer in
>> `RawDeviceRegistration::new`, but I wouldn't bet on it.
>
> Why? The reference is still valid in RawDeviceRegistration::new, no?

Yes the reference is still valid in the `new` function call. I was under
the impression that the pointer created in `new` would get invalidated,
because the struct would get reborrowed in the meantime, but that's not
the case, since this pointer is obtained by `get`. So you should be
good.

>> > +
>> > +                let raw = RawDeviceRegistration::new(opts, parent, data);
>> > +
>> > +                // FIXME: Work around a bug in rustc, to prevent the following warning:
>> > +                //
>> > +                //   "warning: value captured by `dev` is never read."
>> > +                //
>> > +                // Link: https://github.com/rust-lang/rust/issues/141615
>> 
>> Note that the bug is that the compiler complains about the wrong span.
>> The original value of `dev` is `None` and that value is never used, so
>> the warning is justified. So this `let _ = dev;` still needs to stay
>> until `pin-init` supports accessing previously initialized fields (now
>> I'm pretty certain that I will implement that soon).
>
> Do you want to propose an alternative comment about this?

I think we don't need a comment here.

>> > +                let _ = dev;
>> > +
>> > +                if let Some(parent) = parent {
>> > +                    let devres = Devres::new(parent, raw, GFP_KERNEL)?;
>> > +
>> > +                    dev = Some(devres.access(parent)?.device().into());
>> > +                    DeviceRegistrationInner::Managed(devres)
>> > +                } else {
>> > +                    let boxed = KBox::pin_init(raw, GFP_KERNEL)?;
>> > +
>> > +                    dev = Some(boxed.device().into());
>> > +                    DeviceRegistrationInner::Raw(boxed)
>> > +                }
>> > +            },
>> > +            // Cache `this_device` within `Self` to avoid having to access `Devres` in the managed
>> > +            // case.
>> > +            this_device: {
>> > +                // SAFETY: `dev` is guaranteed to be set in the initializer of `inner` above.
>> > +                unsafe { dev.unwrap_unchecked() }
>> > +            },
>> 
>> No need for the extra block, just do:
>> 
>>     // Cache `this_device` within `Self` to avoid having to access `Devres` in the managed
>>     // case.
>>     // SAFETY: `dev` is guaranteed to be set in the initializer of `inner` above.
>>     this_device: unsafe { dev.unwrap_unchecked() },
>
> Yes, I know, but I found the above a bit cleaner -- I don't mind changing it
> though.
>
>> I'm also pretty sure that the compiler would optimize `.take().unwrap()`
>> and also this is only executed once per `MiscDeviceRegistration`, so
>> even if it isn't it wouldn't really matter. So I'd prefer if we don't
>> use `unsafe` here even if it is painfully obvious (if I'm fast enough
>> with implementing, you can rebase on top before you merge and then this
>> will be gone anyways :)
>
> Sounds good! :)
>
> But I think that unsafe is better than unwrap() in such cases; unsafe requires
> us to explain why it's OK to do it, which makes it less likely to create bugs.

That's not exactly how I would think about it, but your argument makes
sense.

> (Just recently I wrote some code, hit the need for unsafe and, while writing up
> the safety comment, I had to explain to myself, why the way I was about to
> implement this was pretty broken.)

That's great :)

> unwrap() on the other hand, doesn't require any explanation, but panics the
> kernel in the worst case.

Yeah that is true. Ultimately for this case it won't matter, since I'll
just implement the access thing in pin-init.

It'll still take a while, because it will touch several parts that other
patches also touch. Thus I prefer to first pick the patches already on
the list, but for that I'll wait until the merge window closes.

---
Cheers,
Benno