[PATCH v4 4/6] rust: rbtree: add mutable iterator

Matt Gilbride posted 6 patches 1 year, 8 months ago
There is a newer version of this series
[PATCH v4 4/6] rust: rbtree: add mutable iterator
Posted by Matt Gilbride 1 year, 8 months ago
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 6ebea833e5a9..28dfa36e81c3 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.
         Iter {
             _tree: PhantomData,
-            // SAFETY: `self.root` is a valid pointer to the tree root.
-            next: unsafe { bindings::rb_first(&self.root) },
+            iter_raw: IterRaw {
+                // 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) },
+                _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) })
+    }
+}
+
+impl<'a, K, V> IntoIterator for &'a mut RBTree<K, V> {
+    type Item = (&'a K, &'a mut V);
+    type IntoIter = IterMut<'a, K, V>;
+
+    fn into_iter(self) -> Self::IntoIter {
+        self.iter_mut()
+    }
+}
+
+/// A mutable iterator over the nodes of a [`RBTree`].
+///
+/// Instances are created by calling [`RBTree::iter_mut`].
+pub struct IterMut<'a, K, V> {
+    _tree: PhantomData<&'a mut RBTree<K, V>>,
+    iter_raw: IterRaw<K, V>,
+}
+
+// SAFETY: The [`RBTreeIterator`] gives out mutable references to K and V, so it has the same
+// thread safety requirements as mutable references.
+unsafe impl<'a, K: Send, V: Send> Send for IterMut<'a, K, V> {}
+
+// SAFETY: The [`RBTreeIterator`] gives out mutable references to K and V, so it has the same
+// thread safety requirements as mutable references.
+unsafe impl<'a, K: Sync, V: Sync> Sync for IterMut<'a, K, V> {}
+
+impl<'a, K, V> Iterator for IterMut<'a, K, V> {
+    type Item = (&'a K, &'a mut V);
+
+    fn next(&mut self) -> Option<Self::Item> {
+        self.iter_raw.next().map(|(k, v)|
+            // SAFETY: Due to `&mut self`, we have exclusive access to `k` and `v`, for the lifetime of `'a`.
+            unsafe { (&*k, &mut *v) })
+    }
+}
+
+/// A raw iterator over the nodes of a [`RBTree`].
+///
+/// # Invariants
+/// - `self.next` is a valid pointer.
+/// - `self.next` points to a node stored inside of a valid `RBTree`.
+struct IterRaw<K, V> {
+    next: *mut bindings::rb_node,
+    _phantom: PhantomData<fn() -> (K, V)>,
+}
+
+impl<K, V> Iterator for IterRaw<K, V> {
+    type Item = (*mut K, *mut V);
+
     fn next(&mut self) -> Option<Self::Item> {
         if self.next.is_null() {
             return None;
         }
 
-        // SAFETY: By the type invariant of `Iter`, `self.next` is a valid node in an `RBTree`,
+        // SAFETY: By the type invariant of `IterRaw`, `self.next` is a valid node in an `RBTree`,
         // and by the type invariant of `RBTree`, all nodes point to the links field of `Node<K, V>` objects.
-        let cur = unsafe { container_of!(self.next, Node<K, V>, links) };
+        let cur: *mut Node<K, V> =
+            unsafe { container_of!(self.next, Node<K, V>, links) }.cast_mut();
 
         // SAFETY: `self.next` is a valid tree node by the type invariants.
         self.next = unsafe { bindings::rb_next(self.next) };
 
-        // SAFETY: By the same reasoning above, it is safe to dereference the node. Additionally,
-        // it is ok to return a reference to members because the iterator must outlive it.
-        Some(unsafe { (&(*cur).key, &(*cur).value) })
+        // SAFETY: By the same reasoning above, it is safe to dereference the node.
+        Some(unsafe { (addr_of_mut!((*cur).key), addr_of_mut!((*cur).value)) })
     }
 }
 

-- 
2.45.1.288.g0e0cd299f1-goog
Re: [PATCH v4 4/6] rust: rbtree: add mutable iterator
Posted by Boqun Feng 1 year, 8 months ago
On Mon, Jun 03, 2024 at 04:05:19PM +0000, Matt Gilbride wrote:
[...]
> +/// A mutable iterator over the nodes of a [`RBTree`].
> +///
> +/// Instances are created by calling [`RBTree::iter_mut`].
> +pub struct IterMut<'a, K, V> {
> +    _tree: PhantomData<&'a mut RBTree<K, V>>,
> +    iter_raw: IterRaw<K, V>,
> +}
> +
> +// SAFETY: The [`RBTreeIterator`] gives out mutable references to K and V, so it has the same

s/RBTreeIterator/IterMut ?

Also `IterMut` doesn't give out mutable references to K, which makes
me think...

> +// thread safety requirements as mutable references.
> +unsafe impl<'a, K: Send, V: Send> Send for IterMut<'a, K, V> {}
> +

we can lose the constrains to `K: Sync`, right?

Regards,
Boqun

> +// SAFETY: The [`RBTreeIterator`] gives out mutable references to K and V, so it has the same
> +// thread safety requirements as mutable references.
> +unsafe impl<'a, K: Sync, V: Sync> Sync for IterMut<'a, K, V> {}
> +
> +impl<'a, K, V> Iterator for IterMut<'a, K, V> {
> +    type Item = (&'a K, &'a mut V);
> +
> +    fn next(&mut self) -> Option<Self::Item> {
> +        self.iter_raw.next().map(|(k, v)|
> +            // SAFETY: Due to `&mut self`, we have exclusive access to `k` and `v`, for the lifetime of `'a`.
> +            unsafe { (&*k, &mut *v) })
> +    }
> +}
> +
[...]
Re: [PATCH v4 4/6] rust: rbtree: add mutable iterator
Posted by Alice Ryhl 1 year, 8 months ago
On Mon, Jun 3, 2024 at 7:42 PM Boqun Feng <boqun.feng@gmail.com> wrote:
>
> On Mon, Jun 03, 2024 at 04:05:19PM +0000, Matt Gilbride wrote:
> [...]
> > +/// A mutable iterator over the nodes of a [`RBTree`].
> > +///
> > +/// Instances are created by calling [`RBTree::iter_mut`].
> > +pub struct IterMut<'a, K, V> {
> > +    _tree: PhantomData<&'a mut RBTree<K, V>>,
> > +    iter_raw: IterRaw<K, V>,
> > +}
> > +
> > +// SAFETY: The [`RBTreeIterator`] gives out mutable references to K and V, so it has the same
>
> s/RBTreeIterator/IterMut ?
>
> Also `IterMut` doesn't give out mutable references to K, which makes
> me think...
>
> > +// thread safety requirements as mutable references.
> > +unsafe impl<'a, K: Send, V: Send> Send for IterMut<'a, K, V> {}
> > +
>
> we can lose the constrains to `K: Sync`, right?

Either Send or Sync would be valid here, but almost all types that are
Sync are also Send, but the opposite is not the case. So I wouldn't
consider that to be loosening the constrain.

Alice
Re: [PATCH v4 4/6] rust: rbtree: add mutable iterator
Posted by Boqun Feng 1 year, 8 months ago
On Mon, Jun 03, 2024 at 07:52:36PM +0200, Alice Ryhl wrote:
> On Mon, Jun 3, 2024 at 7:42 PM Boqun Feng <boqun.feng@gmail.com> wrote:
> >
> > On Mon, Jun 03, 2024 at 04:05:19PM +0000, Matt Gilbride wrote:
> > [...]
> > > +/// A mutable iterator over the nodes of a [`RBTree`].
> > > +///
> > > +/// Instances are created by calling [`RBTree::iter_mut`].
> > > +pub struct IterMut<'a, K, V> {
> > > +    _tree: PhantomData<&'a mut RBTree<K, V>>,
> > > +    iter_raw: IterRaw<K, V>,
> > > +}
> > > +
> > > +// SAFETY: The [`RBTreeIterator`] gives out mutable references to K and V, so it has the same
> >
> > s/RBTreeIterator/IterMut ?
> >
> > Also `IterMut` doesn't give out mutable references to K, which makes
> > me think...
> >
> > > +// thread safety requirements as mutable references.
> > > +unsafe impl<'a, K: Send, V: Send> Send for IterMut<'a, K, V> {}
> > > +
> >
> > we can lose the constrains to `K: Sync`, right?
> 
> Either Send or Sync would be valid here, but almost all types that are
> Sync are also Send, but the opposite is not the case. So I wouldn't
> consider that to be loosening the constrain.
> 

You are probably right. But it's a bit pity that we miss the `Sync` +
`!Send` case :-/

Regards,
Boqun

> Alice