linux-kernel - Re: [PATCH v2 3/5] rust: maple_tree: add MapleTree::lock() and load()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <FD22178C-8BCE-478B-8A2A-12FEFFA8DFC3@collabora.com>
Date: Fri, 22 Aug 2025 12:43:20 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: "Liam R. Howlett" <Liam.Howlett@...cle.com>
Cc: Alice Ryhl <aliceryhl@...gle.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
 Miguel Ojeda <ojeda@...nel.org>,
 Andrew Ballance <andrewjballance@...il.com>,
 Boqun Feng <boqun.feng@...il.com>,
 Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Benno Lossin <lossin@...nel.org>,
 Andreas Hindborg <a.hindborg@...nel.org>,
 Trevor Gross <tmgross@...ch.edu>,
 Danilo Krummrich <dakr@...nel.org>,
 linux-kernel@...r.kernel.org,
 maple-tree@...ts.infradead.org,
 rust-for-linux@...r.kernel.org,
 linux-mm@...ck.org
Subject: Re: [PATCH v2 3/5] rust: maple_tree: add MapleTree::lock() and load()

Hi Liam,

[…]

>> 
>>> +    ///
>>> +    /// # Examples
>>> +    ///
>>> +    /// Iterate the maple tree.
>>> +    ///
>>> +    /// ```
>>> +    /// use kernel::maple_tree::{MapleTree, InsertErrorKind};
>>> +    /// use kernel::sync::Arc;
>>> +    ///
>>> +    /// let tree = KBox::pin_init(MapleTree::<Arc<i32>>::new(), GFP_KERNEL)?;
>>> +    ///
>>> +    /// let ten = Arc::new(10, GFP_KERNEL)?;
>>> +    /// let twenty = Arc::new(20, GFP_KERNEL)?;
>>> +    /// tree.insert(100, ten, GFP_KERNEL)?;
>>> +    /// tree.insert(200, twenty, GFP_KERNEL)?;
>>> +    ///
>>> +    /// let mut ma_lock = tree.lock();
>>> +    /// let mut iter = ma_lock.ma_state(0, usize::MAX);
>>> +    ///
>>> +    /// assert_eq!(*iter.mas_find(usize::MAX).unwrap(), 10);
>>> +    /// assert_eq!(*iter.mas_find(usize::MAX).unwrap(), 20);
>>> +    /// assert!(iter.mas_find(usize::MAX).is_none());
>>> +    /// # Ok::<_, Error>(())
>>> +    /// ```
>>> +    #[inline]
>>> +    pub fn mas_find(&mut self, max: usize) -> Option<T::BorrowedMut<'_>> {
>> 
>> Should we drop the “mas” prefix here? I think that “find()” is fine.
> 
> The maple tree has two interfaces, the advanced one which starts with
> mas_ and the simple on that uses mt_.  This is probably why the mas_ is
> here?
> 

Yeah but we should probably not expose this nomenclature directly in Rust, or
at least not in the function name itself. Perhaps we can implement the mt_* API
as a separate type, with its own find() function?

— Daniel