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 <[email protected]> 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/[email protected]?part=5
