mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andreas Hindborg <a.hindborg@kernel.org>
To: Oliver Mangold <oliver.mangold@pm.me>
Cc: "Miguel Ojeda" <ojeda@kernel.org>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Asahi Lina" <lina@asahilina.net>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v9 3/5] rust: Add missing SAFETY documentation for ARef example
Date: Fri, 02 May 2025 13:33:53 +0200	[thread overview]
Message-ID: <87cycrz1pa.fsf@kernel.org> (raw)
In-Reply-To: <87o6wbz46a.fsf@kernel.org> (Andreas Hindborg's message of "Fri, 02 May 2025 12:40:29 +0200")

Andreas Hindborg <a.hindborg@kernel.org> writes:

> Oliver Mangold <oliver.mangold@pm.me> writes:
>
>> On 250409 1126, Andreas Hindborg wrote:
>>> "Oliver Mangold" <oliver.mangold@pm.me> writes:
>>> 
>>> > SAFETY comment in rustdoc example was just 'TODO'. Fixed.
>>> >
>>> > Signed-off-by: Oliver Mangold <oliver.mangold@pm.me>
>>> > ---
>>> >  rust/kernel/types.rs | 4 ++--
>>> >  1 file changed, 2 insertions(+), 2 deletions(-)
>>> >
>>> > diff --git a/rust/kernel/types.rs b/rust/kernel/types.rs
>>> > index c8b78bcad259132808cc38c56b9f2bd525a0b755..db29f7c725e631c11099fa9122901ec2b3f4a039 100644
>>> > --- a/rust/kernel/types.rs
>>> > +++ b/rust/kernel/types.rs
>>> > @@ -492,7 +492,7 @@ pub unsafe fn from_raw(ptr: NonNull<T>) -> Self {
>>> >      ///
>>> >      /// struct Empty {}
>>> >      ///
>>> > -    /// # // SAFETY: TODO.
>>> > +    /// // SAFETY: We do not free anything.
>>> 
>>> How about:
>>> 
>>>   This implementation will never free the underlying object, so the
>>>   object is kept alive longer than the safety requirement specifies.
>>
>> Yes, was rather sloppy wording. Thanks, I will use your version.
>>
>>> >      /// unsafe impl RefCounted for Empty {
>>> >      ///     fn inc_ref(&self) {}
>>> >      ///     unsafe fn dec_ref(_obj: NonNull<Self>) {}
>>> > @@ -500,7 +500,7 @@ pub unsafe fn from_raw(ptr: NonNull<T>) -> Self {
>>> >      ///
>>> >      /// let mut data = Empty {};
>>> >      /// let ptr = NonNull::<Empty>::new(&mut data).unwrap();
>>> > -    /// # // SAFETY: TODO.
>>> > +    /// // SAFETY: We keep `data` around longer than the `ARef`.
>>> 
>>> This is not sufficient. The safety requirement is:
>>> 
>>>   Callers must ensure that the reference count was incremented at least once, and that they
>>>   are properly relinquishing one increment. That is, if there is only one increment, callers
>>>   must not use the underlying object anymore -- it is only safe to do so via the newly
>>>   created [`ARef`].
>>> 
>>> How about:
>>> 
>>>   The `RefCounted` implementation for `Empty` does not count references
>>>   and never frees the underlying object. Thus we can act as having a
>>>   refcount on the object that we pass to the newly created `ARef`.
>>> 
>>> I think this example actually exposes a soundness hole. When the
>>> underlying object is allocated on the stack, the safety requirements are
>>> not sufficient to ensure the lifetime of the object. We could safely
>>> return `data_ref` and have the underlying object go away. We should add
>>> to the safety requirement of `ARef::from_raw`:
>>> 
>>>   `ptr` must be valid while the refcount is positive.
>>
>> Wouldn't this already be covered by the below in the doc for
>> AlwaysRefCounted?
>>
>>     Implementers must ensure that increments to the reference count keep
>>     the object alive in memory at least until matching decrements are
>>     performed."
>
> No, I don't think that is enough. We can implement the trait properly
> with refcounts and still we can allocate an object on the stack and then
> do a `from_raw` on that object without violating any safety
> requirements. I think the `ARef::from_raw` should have the safety
> requirement above. But we can do that as a separate patch.

On second thought, I think you are right. I was trying to implement a
counter example, and I think it is not possible to implement
`RefCounted` while following the safety requirements in a way that would
trigger this issue. Implementers will have to make sure that the the
type that implement `RefCounted` cannot be directly constructed. In
other words the implementation for `Empty` is illegal in this regard.

We can do this instead for the example


    mod empty {
        use crate::alloc::KBox;
        use core::ptr::NonNull;

        pub struct Empty {
            // Prevent direct construction
            _p: (),
        }

        // SAFETY: The `RefCounted` implementation for `Empty` does not count references
        // and never frees the underlying object. Thus we can act as having a
        // refcount on the object that we pass to the newly created `ARef`.
        unsafe impl super::RefCounted for Empty {
            fn inc_ref(&self) {}

            unsafe fn dec_ref(_obj: NonNull<Self>) {}
        }

        impl Empty {
            pub fn new() -> NonNull<Self> {
                NonNull::new(KBox::into_raw(
                    KBox::new(Self { _p: () }, kernel::alloc::flags::GFP_KERNEL).unwrap(),
                ))
                .unwrap()
            }
        }
    }

    let ptr = empty::Empty::new();

    // SAFETY: The `RefCounted` implementation for `Empty` does not count
    // references and never frees the underlying object. Thus we can act as
    // having a refcount on the object that we pass to the newly created `ARef`.
    let data_ref: ARef<empty::Empty> = unsafe { ARef::from_raw(ptr) };
    let _raw_ptr: NonNull<empty::Empty> = ARef::into_raw(data_ref);



Best regards,
Andreas Hindborg



  reply	other threads:[~2025-05-02 11:34 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-25 11:56 [PATCH v9 0/5] New trait OwnableRefCounted for ARef<->Owned conversion Oliver Mangold
2025-03-25 11:56 ` [PATCH v9 1/5] rust: types: Add Ownable/Owned types Oliver Mangold
2025-04-09  8:34   ` Andreas Hindborg
2025-04-15  6:01     ` Oliver Mangold
2025-03-25 11:57 ` [PATCH v9 2/5] rust: Rename AlwaysRefCounted to RefCounted Oliver Mangold
2025-03-26 17:29   ` kernel test robot
2025-04-09  8:41   ` Andreas Hindborg
2025-03-25 11:57 ` [PATCH v9 3/5] rust: Add missing SAFETY documentation for ARef example Oliver Mangold
2025-04-09  9:26   ` Andreas Hindborg
2025-04-15  6:07     ` Oliver Mangold
2025-05-02 10:40       ` Andreas Hindborg
2025-05-02 11:33         ` Andreas Hindborg [this message]
2025-03-25 11:57 ` [PATCH v9 4/5] rust: kbuild: provide `RUSTC_HAS_DO_NOT_RECOMMEND` symbol Oliver Mangold
2025-04-09  9:27   ` Andreas Hindborg
2025-03-25 11:57 ` [PATCH v9 5/5] rust: Add OwnableRefCounted and SimpleOwnableRefCounted Oliver Mangold
2025-04-09 10:17   ` Andreas Hindborg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87cycrz1pa.fsf@kernel.org \
    --to=a.hindborg@kernel.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=gary@garyguo.net \
    --cc=lina@asahilina.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=oliver.mangold@pm.me \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tmgross@umich.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®