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

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aFrPKAxHfAetcQzz@cassiopeiae>
Date: Tue, 24 Jun 2025 18:15:36 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Boqun Feng <boqun.feng@...il.com>
Cc: gregkh@...uxfoundation.org, rafael@...nel.org, ojeda@...nel.org,
	alex.gaynor@...il.com, gary@...yguo.net, bjorn3_gh@...tonmail.com,
	lossin@...nel.org, 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 v2 3/4] rust: devres: get rid of Devres' inner Arc

On Tue, Jun 24, 2025 at 08:46:53AM -0700, Boqun Feng wrote:
> 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()`...

Oh, so you meant adding this to the safety comment. Yes, that makes sense. Maybe
ScopeGuard works too, as you say.