All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Hindborg <a.hindborg@kernel.org>
To: "Alice Ryhl" <aliceryhl@google.com>
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>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Oliver Mangold" <oliver.mangold@pm.me>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rust: elaborate safety requirements for `AlwaysReferenceCounted`
Date: Fri, 02 May 2025 15:46:46 +0200	[thread overview]
Message-ID: <87jz6zxgzd.fsf@kernel.org> (raw)
In-Reply-To: <CAH5fLgj3j2BEyOmVw+T_988e_h1TYRmYVuEDYaL-baRu_mQq4g@mail.gmail.com> (Alice Ryhl's message of "Fri, 02 May 2025 14:37:19 +0200")

"Alice Ryhl" <aliceryhl@google.com> writes:

> On Fri, May 2, 2025 at 2:32 PM Andreas Hindborg <a.hindborg@kernel.org> wrote:
>>
>> "Alice Ryhl" <aliceryhl@google.com> writes:
>>
>> > On Fri, May 02, 2025 at 01:53:57PM +0200, Andreas Hindborg wrote:
>> >> Clarify that implementers of `AlwaysReferenceCounted` must prevent the
>> >> implementer from being directly initialized by users.
>> >>
>> >> It is a violation of the safety requirements of `AlwaysReferenceCounted` if
>> >> its implementers can be initialized on the stack by users. Although this
>> >> follows from the safety requirements, it is not immediately obvious.
>> >>
>> >> The following example demonstrates the issue. Note that the safety
>> >> requirements for implementing `AlwaysRefCounted` and for calling
>> >> `ARef::from_raw` are satisfied.
>> >>
>> >>   struct Empty {}
>> >>
>> >>   unsafe impl AlwaysRefCounted for Empty {
>> >>       fn inc_ref(&self) {}
>> >>       unsafe fn dec_ref(_obj: NonNull<Self>) {}
>> >>   }
>> >>
>> >>   fn unsound() -> ARef<Empty> {
>> >>       use core::ptr::NonNull;
>> >>       use kernel::types::{ARef, RefCounted};
>> >>
>> >>       let mut data = Empty {};
>> >>       let ptr = NonNull::<Empty>::new(&mut data).unwrap();
>> >>       let aref: ARef<Empty> = unsafe { ARef::from_raw(ptr) };
>> >>
>> >>       aref
>> >>   }
>> >
>> > I don't think it's entirely impossible to write an AlwaysRefCounted
>> > value that can be on the stack. The type just needs a lifetime
>> > parameter. For example, this API is not unsound:
>> >
>> > struct MyDataStorage {
>> >     // ...
>> > }
>> >
>> > impl MyDataStorage {
>> >     fn as_aref(&self) -> ARef<MyData<'_>> {
>> >         unsafe { ARef::from_raw(ptr::from_ref(self).cast()) }
>> >     }
>> > }
>> >
>> > #[repr(transparent)]
>> > struct MyData<'s> {
>> >     storage: MyDataStorage,
>> >     _lifetime: PhantomData<&'s MyDataStorage>,
>> > }
>> >
>> > unsafe impl AlwaysRefCounted for MyData<'_> {
>> >     fn inc_ref(&self) {}
>> >     unsafe fn dec_ref(_obj: NonNull<Self>) {}
>> > }
>> >
>> > impl Deref for MyData<'_> {
>> >     type Target = MyDataStorage;
>> >     fn deref(&self) -> &MyDataStorage {
>> >         &self.storage
>> >     }
>> > }
>>
>> Right. I would rephrase then:
>>
>> It is a violation of the safety requirements of `AlwaysReferenceCounted`
>> if its implementers can be initialized on the stack by users and an
>> `ARef` referencing the object can outlive the object. Although this follows from
>> the safety requirements, it is not immediately obvious.
>>
>> and
>>
>> +/// Note: This means that implementers must prevent users from directly
>> +/// initializing the implementer when the implementer is `'static`. Otherwise users could
>> +/// initialize the implementer on
>> +/// the stack, which would violate the safety requirements.
>>
>> What do you think?
>
> Hmm. Perhaps we should say that you can never own it "by value". There
> must always be pointer indirection.

Yes, that could work. I'll send a new version.


Best regards,
Andreas Hindborg





      reply	other threads:[~2025-05-02 13:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-02 11:53 [PATCH] rust: elaborate safety requirements for `AlwaysReferenceCounted` Andreas Hindborg
2025-05-02 12:02 ` Alice Ryhl
2025-05-02 12:31   ` Andreas Hindborg
2025-05-02 12:37     ` Alice Ryhl
2025-05-02 13:46       ` Andreas Hindborg [this message]

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=87jz6zxgzd.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=dakr@kernel.org \
    --cc=gary@garyguo.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.