From: Benno Lossin <benno.lossin@proton.me>
To: Alice Ryhl <aliceryhl@google.com>
Cc: "Matt Gilbride" <mattgilbride@google.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"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>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Arve Hjønnevåg" <arve@android.com>,
"Todd Kjos" <tkjos@android.com>,
"Martijn Coenen" <maco@android.com>,
"Joel Fernandes" <joel@joelfernandes.org>,
"Carlos Llamas" <cmllamas@google.com>,
"Suren Baghdasaryan" <surenb@google.com>,
"Christian Brauner" <brauner@kernel.org>,
"Rob Landley" <rob@landley.net>,
"Davidlohr Bueso" <dave@stgolabs.net>,
"Michel Lespinasse" <michel@lespinasse.org>,
rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v8 4/6] rust: rbtree: add mutable iterator
Date: Tue, 06 Aug 2024 09:23:55 +0000 [thread overview]
Message-ID: <2617ec4a-6413-4341-b4fe-c30c1b14432e@proton.me> (raw)
In-Reply-To: <CAH5fLghJmA_01QJvzSBX4HEfLwPr+FskM9dzOs0ykbYj_sCWTg@mail.gmail.com>
On 06.08.24 10:30, Alice Ryhl wrote:
> On Mon, Aug 5, 2024 at 9:22 PM Benno Lossin <benno.lossin@proton.me> wrote:
>>
>> On 27.07.24 22:30, Matt Gilbride wrote:
>>> From: Wedson Almeida Filho <wedsonaf@gmail.com>
>>>
>>> Add mutable Iterator implementation for `RBTree`,
>>> allowing iteration over (key, value) pairs in key order. Only values are
>>> mutable, as mutating keys implies modifying a node's position in the tree.
>>>
>>> Mutable iteration is used by the binder driver during shutdown to
>>> clean up the tree maintained by the "range allocator" [1].
>>>
>>> Link: https://lore.kernel.org/rust-for-linux/20231101-rust-binder-v1-6-08ba9197f637@google.com/ [1]
>>> Signed-off-by: Wedson Almeida Filho <wedsonaf@gmail.com>
>>> Signed-off-by: Matt Gilbride <mattgilbride@google.com>
>>> Reviewed-by: Alice Ryhl <aliceryhl@google.com>
>>> Tested-by: Alice Ryhl <aliceryhl@google.com>
>>> ---
>>> rust/kernel/rbtree.rs | 98 ++++++++++++++++++++++++++++++++++++++++++++-------
>>> 1 file changed, 86 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/rust/kernel/rbtree.rs b/rust/kernel/rbtree.rs
>>> index d10074e4ac58..d7514ebadfa8 100644
>>> --- a/rust/kernel/rbtree.rs
>>> +++ b/rust/kernel/rbtree.rs
>>> @@ -197,8 +197,26 @@ pub fn iter(&self) -> Iter<'_, K, V> {
>>> // INVARIANT: `bindings::rb_first` returns a valid pointer to a tree node given a valid pointer to a tree root.
>>
>> This INVARIANT is out of place, `Iter` doesn't have any INVARIANT any
>> more.
>
> We can delete it.
>
>>> Iter {
>>> _tree: PhantomData,
>>> - // SAFETY: `self.root` is a valid pointer to the tree root.
>>> - next: unsafe { bindings::rb_first(&self.root) },
>>> + iter_raw: IterRaw {
>>
>> This `IterRaw` construction is missing an INVARIANT comment. I think you
>> can copy paste from below.
>
> We can copy from below.
>
>>> + // SAFETY: by the invariants, all pointers are valid.
>>> + next: unsafe { bindings::rb_first(&self.root) },
>>> + _phantom: PhantomData,
>>> + },
>>> + }
>>> + }
>>> +
>>> + /// Returns a mutable iterator over the tree nodes, sorted by key.
>>> + pub fn iter_mut(&mut self) -> IterMut<'_, K, V> {
>>> + IterMut {
>>> + _tree: PhantomData,
>>> + // INVARIANT:
>>> + // - `self.root` is a valid pointer to a tree root.
>>> + // - `bindings::rb_first` produces a valid pointer to a node given `root` is valid.
>>> + iter_raw: IterRaw {
>>> + // SAFETY: by the invariants, all pointers are valid.
>>> + next: unsafe { bindings::rb_first(&self.root) },
>>
>> Does this really derive a mutable reference? Ie shouldn't this be:?
>>
>> next: unsafe { bindings::rb_first(&mut self.root) },
>
> Let's change this to:
>
> next: unsafe { bindings::rb_first(ptr::from_mut(&mut self.root)) }
>
> This way, the pointer will be derived from a mutable reference even if
> it becomes a `*const` through intermediate operations.
SGTM
>
>
>>> + _phantom: PhantomData,
>>> + },
>>> }
>>> }
>>>
>>> @@ -211,6 +229,11 @@ pub fn keys(&self) -> impl Iterator<Item = &'_ K> {
>>> pub fn values(&self) -> impl Iterator<Item = &'_ V> {
>>> self.iter().map(|(_, v)| v)
>>> }
>>> +
>>> + /// Returns a mutable iterator over the values of the nodes in the tree, sorted by key.
>>> + pub fn values_mut(&mut self) -> impl Iterator<Item = &'_ mut V> {
>>> + self.iter_mut().map(|(_, v)| v)
>>> + }
>>> }
>>>
>>> impl<K, V> RBTree<K, V>
>>> @@ -414,13 +437,9 @@ fn into_iter(self) -> Self::IntoIter {
>>> /// An iterator over the nodes of a [`RBTree`].
>>> ///
>>> /// Instances are created by calling [`RBTree::iter`].
>>> -///
>>> -/// # Invariants
>>> -/// - `self.next` is a valid pointer.
>>> -/// - `self.next` points to a node stored inside of a valid `RBTree`.
>>> pub struct Iter<'a, K, V> {
>>> _tree: PhantomData<&'a RBTree<K, V>>,
>>> - next: *mut bindings::rb_node,
>>> + iter_raw: IterRaw<K, V>,
>>> }
>>>
>>> // SAFETY: The [`Iter`] gives out immutable references to K and V, so it has the same
>>> @@ -434,21 +453,76 @@ unsafe impl<'a, K: Sync, V: Sync> Sync for Iter<'a, K, V> {}
>>> impl<'a, K, V> Iterator for Iter<'a, K, V> {
>>> type Item = (&'a K, &'a V);
>>>
>>> + fn next(&mut self) -> Option<Self::Item> {
>>> + self.iter_raw.next().map(|(k, v)|
>>> + // SAFETY: Due to `self._tree`, `k` and `v` are valid for the lifetime of `'a`.
>>> + unsafe { (&*k, &*v) })
>>
>> I don't really like the formatting here, can you move the SAFETY one
>> line upwards? It should format nicely then.
>
> You suggested exactly the reverse formatting change on RBTreeCursor?
Do you mean on this version or in a previous one? If you mean in this
one, then I would argue that they are not "reverses" of each other. For
this instance I would prefer
// SAFETY: Due to `self._tree`, `k` and `v` are valid for the lifetime of `'a`.
self.iter_raw.next().map(|(k, v)| unsafe { (&*k, &*v) })
or
self.iter_raw.next().map(|(k, v)| {
// SAFETY: Due to `self._tree`, `k` and `v` are valid for the lifetime of `'a`.
unsafe { (&*k, &*v) }
})
I hope that this seems consistent, my motivation behind the suggestions
are that I don't like the comment splitting the single line.
---
Cheers,
Benno
next prev parent reply other threads:[~2024-08-06 9:24 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-27 20:30 [PATCH v8 0/6] Red-black tree abstraction needed by Rust Binder Matt Gilbride
2024-07-27 20:30 ` [PATCH v8 1/6] rust: kernel: add `drop_contents` to `BoxExt` Matt Gilbride
2024-08-01 9:00 ` Alice Ryhl
2024-08-01 9:02 ` Alice Ryhl
2024-07-27 20:30 ` [PATCH v8 2/6] rust: rbtree: add red-black tree implementation backed by the C version Matt Gilbride
2024-07-30 21:54 ` Boqun Feng
2024-07-30 21:56 ` Boqun Feng
2024-08-05 19:02 ` Benno Lossin
2024-08-06 8:41 ` Alice Ryhl
2024-08-06 8:51 ` Benno Lossin
2024-07-27 20:30 ` [PATCH v8 3/6] rust: rbtree: add iterator Matt Gilbride
2024-08-05 19:08 ` Benno Lossin
2024-07-27 20:30 ` [PATCH v8 4/6] rust: rbtree: add mutable iterator Matt Gilbride
2024-08-05 19:22 ` Benno Lossin
2024-08-06 8:30 ` Alice Ryhl
2024-08-06 9:23 ` Benno Lossin [this message]
2024-07-27 20:30 ` [PATCH v8 5/6] rust: rbtree: add `RBTreeCursor` Matt Gilbride
2024-08-05 19:35 ` Benno Lossin
2024-08-06 8:24 ` Alice Ryhl
2024-08-06 9:01 ` Benno Lossin
2024-08-06 9:04 ` Alice Ryhl
2024-08-06 9:27 ` Benno Lossin
2024-07-27 20:30 ` [PATCH v8 6/6] rust: rbtree: add `RBTree::entry` Matt Gilbride
2024-08-05 20:02 ` Benno Lossin
2024-08-06 8:39 ` Alice Ryhl
2024-07-30 21:57 ` [PATCH v8 0/6] Red-black tree abstraction needed by Rust Binder Boqun Feng
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=2617ec4a-6413-4341-b4fe-c30c1b14432e@proton.me \
--to=benno.lossin@proton.me \
--cc=a.hindborg@samsung.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=arve@android.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=brauner@kernel.org \
--cc=cmllamas@google.com \
--cc=dave@stgolabs.net \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maco@android.com \
--cc=mattgilbride@google.com \
--cc=michel@lespinasse.org \
--cc=ojeda@kernel.org \
--cc=rob@landley.net \
--cc=rust-for-linux@vger.kernel.org \
--cc=surenb@google.com \
--cc=tkjos@android.com \
--cc=wedsonaf@gmail.com \
/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®