Re: [PATCH v2 3/4] rust: devres: get rid of Devres' inner Arc

[Boqun Feng <boqun.feng@gmail.com>]

On Tue, Jun 24, 2025 at 05:18:23PM +0200, Danilo Krummrich wrote:
> On Sun, Jun 22, 2025 at 06:54:07PM -0700, Boqun Feng wrote:
> > I think you also need to mention that `inner` only remains valid until
> > `inner.devm.complete_all()` unblocks `Devres::drop()`, because after
> > `Devres::drop()`'s `devm.wait_for_completion()` returns, `inner` may be
> > dropped or freed.
> 
> I think of it the other way around: The invariant guarantees that `inner` is
> *always* valid.
> 
> The the `drop_in_place(inner)` call has to justify that it upholds this
> invariant, by ensuring that at the time it is called no other code that accesses
> `inner` can ever run.
> 
> Defining it the other way around would make the `inner()` accessor unsafe.

Maybe I wasn't clear enough, I meant in the following function:

    unsafe extern "C" fn devres_callback(ptr: *mut kernel::ffi::c_void) {
-        let ptr = ptr as *mut DevresInner<T>;
-        // Devres owned this memory; now that we received the callback, drop the `Arc` and hence the
-        // reference.
-        // SAFETY: Safe, since we leaked an `Arc` reference to devm_add_action() in
-        //         `DevresInner::new`.
-        let inner = unsafe { Arc::from_raw(ptr) };
+        // SAFETY: In `Self::new` we've passed a valid pointer to `Inner` to `devm_add_action()`,
+        // hence `ptr` must be a valid pointer to `Inner`.
+        let inner = unsafe { &*ptr.cast::<Inner<T>>() };

^ this `inner` was constructed by reborrowing from `ptr`, but it should
only be used before the following `inner.devm.complete_all()`...

         if !inner.data.revoke() {
             // If `revoke()` returns false, it means that `Devres::drop` already started revoking
-            // `inner.data` for us. Hence we have to wait until `Devres::drop()` signals that it
-            // completed revoking `inner.data`.
+            // `data` for us. Hence we have to wait until `Devres::drop` signals that it
+            // completed revoking `data`.
             inner.revoke.wait_for_completion();
[...]
+        // Signal that we're done using `inner`.
+        inner.devm.complete_all();

... because the `DevresInner` might be freed after we signal the
`Devres::drop()`. And for example, doing a:

    inner.data.try_access();

after the above line would be unsound.

+    }

And I would prefer we document this or use `ScopeGuard`, does it make
sense?

Regards,
Boqun