Re: [PATCH v21 5/9] rust: Add missing SAFETY documentation for `ARef` example

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The newly added SAFETY comments justify an unsound implementation of `RefCounted` by pushing the trait's liveness invariants onto the caller.
--

commit 368d99cfa43beab2cba1151e1e06c503881e1ab5
Author: Oliver Mangold <oliver.mangold@pm.me>

rust: Add missing SAFETY documentation for `ARef` example

This commit replaces a TODO comment with a detailed SAFETY comment in the
rustdoc example for ARef, explaining why the dummy RefCounted implementation
and subsequent ARef creation are considered safe.

Link: https://github.com/Rust-for-Linux/linux/issues/351

> diff --git a/rust/kernel/sync/aref.rs b/rust/kernel/sync/aref.rs
> index 215e7eb139fac..ae76bd9b6c1c9 100644
> --- a/rust/kernel/sync/aref.rs
> +++ b/rust/kernel/sync/aref.rs
> @@ -147,7 +147,10 @@ pub unsafe fn from_raw(ptr: NonNull<T>) -> Self {
>      ///
>      /// struct Empty {}
>      ///
> -    /// # // SAFETY: TODO.
> +    /// // SAFETY: The `RefCounted` implementation for `Empty` does not count references, and
> +    /// // `dec_ref` never frees the underlying object, so a decrement cannot invalidate it. The
> +    /// // object instead lives as long as the `Empty` value itself, so creators of `ARef<Empty>`
> +    /// // must guarantee that the value outlives every `ARef` derived from it (as done below).

[Severity: Medium]
Does this pattern violate the safety contract of the RefCounted trait?

The documentation teaches an approach where creators of ARef<Empty> must
guarantee that the value outlives every ARef derived from it. Since ARef<T>
provides a safe Clone method and does not carry a lifetime parameter, it is
impossible for the creator to enforce this guarantee if the ARef is cloned
and sent to another thread.

If a developer copies this reasoning to implement RefCounted for a type
where inc_ref does not actually maintain liveness, could a cloned ARef
outlive the underlying object and cause a use-after-free vulnerability in
safe Rust?

>      /// unsafe impl RefCounted for Empty {
>      ///     fn inc_ref(&self) {}
>      ///     unsafe fn dec_ref(_obj: NonNull<Self>) {}
> @@ -155,7 +158,9 @@ pub unsafe fn from_raw(ptr: NonNull<T>) -> Self {
>      ///
>      /// let mut data = Empty {};
>      /// let ptr = NonNull::<Empty>::new(&mut data).unwrap();
> -    /// # // SAFETY: TODO.
> +    /// // SAFETY: As the refcount operations of `Empty` are no-ops, we can treat `ptr` as owning
> +    /// // an increment on the refcount. `data` outlives the created `ARef`, upholding the
> +    /// // liveness guarantee required by the `RefCounted` implementation above.

[Severity: Medium]
Since the liveness guarantee mentioned in the RefCounted implementation above
cannot be statically enforced by the caller during safe ARef clones, does
this initialization rely on an unsound guarantee?

>      /// let data_ref: ARef<Empty> = unsafe { ARef::from_raw(ptr) };
>      /// let raw_ptr: NonNull<Empty> = ARef::into_raw(data_ref);
>      ///

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260910-unique-ref-v21-0-e83257373062@kernel.org?part=5