From: Benno Lossin <benno.lossin@proton.me>
To: Alice Ryhl <aliceryhl@google.com>,
Miguel Ojeda <ojeda@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: "Alex Gaynor" <alex.gaynor@gmail.com>,
"Wedson Almeida Filho" <wedsonaf@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Andreas Hindborg" <a.hindborg@samsung.com>,
"Marco Elver" <elver@google.com>,
"Kees Cook" <keescook@chromium.org>, "Coly Li" <colyli@suse.de>,
"Paolo Abeni" <pabeni@redhat.com>,
"Pierre Gondois" <pierre.gondois@arm.com>,
"Ingo Molnar" <mingo@kernel.org>,
"Jakub Kicinski" <kuba@kernel.org>,
"Wei Yang" <richard.weiyang@gmail.com>,
"Matthew Wilcox" <willy@infradead.org>,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v2 2/9] rust: list: add tracking for ListArc
Date: Mon, 27 May 2024 09:39:38 +0000 [thread overview]
Message-ID: <35544d52-166a-45a0-ae60-b39ecde576bc@proton.me> (raw)
In-Reply-To: <20240506-linked-list-v2-2-7b910840c91f@google.com>
On 06.05.24 11:53, Alice Ryhl wrote:
> @@ -32,9 +33,24 @@ pub trait ListArcSafe<const ID: u64 = 0> {
> unsafe fn on_drop_list_arc(&self);
> }
>
> +/// Declares that this type is able to safely attempt to create `ListArc`s at any time.
> +///
> +/// # Safety
> +///
> +/// Implementers must ensure that `try_new_list_arc` does not return `true` if a `ListArc` already
> +/// exists.
> +pub unsafe trait TryNewListArc<const ID: u64 = 0>: ListArcSafe<ID> {
> + /// Attempts to convert an `Arc<Self>` into an `ListArc<Self>`. Returns `true` if the
> + /// conversion was successful.
> + fn try_new_list_arc(&self) -> bool;
> +}
> +
> /// Declares that this type supports [`ListArc`].
> ///
> -/// When using this macro, it will only be possible to create a [`ListArc`] from a [`UniqueArc`].
> +/// When using this macro, you may choose between the `untracked` strategy where it is not tracked
> +/// whether a [`ListArc`] exists, and the `tracked_by` strategy where the tracking is deferred to a
> +/// field of the struct. The `tracked_by` strategy can be combined with a field of type
> +/// [`AtomicListArcTracker`] to track whether a [`ListArc`] exists.
I think it would make sense to use bullet points here.
Also, you should mention that in the `tracked_by` strategy, the field is
required to implement `TryNewListArc`.
> #[macro_export]
> macro_rules! impl_list_arc_safe {
> (impl$({$($generics:tt)*})? ListArcSafe<$num:tt> for $t:ty { untracked; } $($rest:tt)*) => {
> @@ -45,6 +61,37 @@ unsafe fn on_drop_list_arc(&self) {}
> $crate::list::impl_list_arc_safe! { $($rest)* }
> };
>
> + (impl$({$($generics:tt)*})? ListArcSafe<$num:tt> for $t:ty {
> + tracked_by $field:ident : $fty:ty;
> + } $($rest:tt)*) => {
> + impl$(<$($generics)*>)? $crate::list::ListArcSafe<$num> for $t {
> + unsafe fn on_create_list_arc_from_unique(self: ::core::pin::Pin<&mut Self>) {
> + // SAFETY: This field is structurally pinned.
Who ensures this? This is not documented on the macro.
The only way that I see to fix this would be to make the `tracked_by`
strategy `unsafe`. At least until we implement proper structural pinning
of fields.
> + let field = unsafe {
> + ::core::pin::Pin::map_unchecked_mut(self, |me| &mut me.$field)
> + };
> + // SAFETY: The caller promises that there is no `ListArc`.
> + unsafe {
> + <$fty as $crate::list::ListArcSafe<$num>>::on_create_list_arc_from_unique(field)
> + };
> + }
> + unsafe fn on_drop_list_arc(&self) {
> + // SAFETY: The caller promises that there is no `ListArc` reference, and also
> + // promises that the tracking thinks there is a `ListArc` reference.
> + unsafe { <$fty as $crate::list::ListArcSafe<$num>>::on_drop_list_arc(&self.$field) };
> + }
> + }
> + unsafe impl$(<$($generics)*>)? $crate::list::TryNewListArc<$num> for $t
> + where
> + $fty: TryNewListArc<$num>,
> + {
> + fn try_new_list_arc(&self) -> bool {
> + <$fty as $crate::list::TryNewListArc<$num>>::try_new_list_arc(&self.field)
> + }
> + }
> + $crate::list::impl_list_arc_safe! { $($rest)* }
> + };
> +
> () => {};
> }
> pub use impl_list_arc_safe;
[...]
> @@ -313,3 +406,60 @@ impl<T, U, const ID: u64> core::ops::DispatchFromDyn<ListArc<U, ID>> for ListArc
> U: ListArcSafe<ID> + ?Sized,
> {
> }
> +
> +/// A utility for tracking whether a [`ListArc`] exists using an atomic.
> +///
> +/// # Invariant
> +///
> +/// If the boolean is `false`, then there is no [`ListArc`] for this value.
"If `inner` is `false`, ..."
---
Cheers,
Benno
> +#[repr(transparent)]
> +pub struct AtomicListArcTracker<const ID: u64 = 0> {
> + inner: AtomicBool,
> + _pin: PhantomPinned,
> +}
[...]
next prev parent reply other threads:[~2024-05-27 9:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-06 9:53 [PATCH v2 0/9] Add Rust linked list for reference counted values Alice Ryhl
2024-05-06 9:53 ` [PATCH v2 1/9] rust: list: add ListArc Alice Ryhl
2024-05-27 9:25 ` Benno Lossin
2024-05-06 9:53 ` [PATCH v2 2/9] rust: list: add tracking for ListArc Alice Ryhl
2024-05-27 9:39 ` Benno Lossin [this message]
2024-05-06 9:53 ` [PATCH v2 3/9] rust: list: add struct with prev/next pointers Alice Ryhl
2024-05-27 9:58 ` Benno Lossin
2024-05-27 11:42 ` Alice Ryhl
2024-05-06 9:53 ` [PATCH v2 4/9] rust: list: add macro for implementing ListItem Alice Ryhl
2024-05-27 10:06 ` Benno Lossin
2024-05-06 9:53 ` [PATCH v2 5/9] rust: list: add List Alice Ryhl
2024-05-27 10:25 ` Benno Lossin
2024-05-06 9:53 ` [PATCH v2 6/9] rust: list: add iterators Alice Ryhl
2024-05-27 10:31 ` Benno Lossin
2024-05-06 9:53 ` [PATCH v2 7/9] rust: list: add cursor Alice Ryhl
2024-05-27 10:37 ` Benno Lossin
2024-05-06 9:53 ` [PATCH v2 8/9] rust: list: support heterogeneous lists Alice Ryhl
2024-05-27 10:46 ` Benno Lossin
2024-05-06 9:53 ` [PATCH v2 9/9] rust: list: add ListArcField Alice Ryhl
2024-05-27 10:50 ` Benno Lossin
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=35544d52-166a-45a0-ae60-b39ecde576bc@proton.me \
--to=benno.lossin@proton.me \
--cc=a.hindborg@samsung.com \
--cc=akpm@linux-foundation.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=colyli@suse.de \
--cc=elver@google.com \
--cc=gary@garyguo.net \
--cc=keescook@chromium.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=ojeda@kernel.org \
--cc=pabeni@redhat.com \
--cc=pierre.gondois@arm.com \
--cc=richard.weiyang@gmail.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=wedsonaf@gmail.com \
--cc=willy@infradead.org \
/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®