linux-kernel - Re: [PATCH v16 3/4] rust: xarray: Add an abstraction for XArray

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <Z7NANGwGPQaGNwIh@cassiopeiae>
Date: Mon, 17 Feb 2025 14:57:08 +0100
From: Danilo Krummrich <dakr@...nel.org>
To: Tamir Duberstein <tamird@...il.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Benno Lossin <benno.lossin@...ton.me>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
	Matthew Wilcox <willy@...radead.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	FUJITA Tomonori <fujita.tomonori@...il.com>,
	"Rob Herring (Arm)" <robh@...nel.org>,
	Maíra Canal <mcanal@...lia.com>,
	Asahi Lina <lina@...hilina.net>, rust-for-linux@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org
Subject: Re: [PATCH v16 3/4] rust: xarray: Add an abstraction for XArray

On Mon, Feb 17, 2025 at 08:43:12AM -0500, Tamir Duberstein wrote:
> On Mon, Feb 17, 2025 at 6:35 AM Danilo Krummrich <dakr@...nel.org> wrote:
> >
> > On Fri, Feb 07, 2025 at 08:58:26AM -0500, Tamir Duberstein wrote:
> > > `XArray` is an efficient sparse array of pointers. Add a Rust
> > > abstraction for this type.
> > >
> > > This implementation bounds the element type on `ForeignOwnable` and
> > > requires explicit locking for all operations. Future work may leverage
> > > RCU to enable lockless operation.
> > >
> > > Inspired-by: Maíra Canal <mcanal@...lia.com>
> > > Inspired-by: Asahi Lina <lina@...hilina.net>
> > > Reviewed-by: Andreas Hindborg <a.hindborg@...nel.org>
> > > Reviewed-by: Alice Ryhl <aliceryhl@...gle.com>
> > > Signed-off-by: Tamir Duberstein <tamird@...il.com>
> > > ---
> > >  rust/bindings/bindings_helper.h |   6 +
> > >  rust/helpers/helpers.c          |   1 +
> > >  rust/helpers/xarray.c           |  28 ++++
> > >  rust/kernel/alloc.rs            |   5 +
> > >  rust/kernel/lib.rs              |   1 +
> > >  rust/kernel/xarray.rs           | 276 ++++++++++++++++++++++++++++++++++++++++
> > >  6 files changed, 317 insertions(+)
> > >
> > > diff --git a/rust/kernel/alloc.rs b/rust/kernel/alloc.rs
> > > index fc9c9c41cd79..77840413598d 100644
> > > --- a/rust/kernel/alloc.rs
> > > +++ b/rust/kernel/alloc.rs
> > > @@ -39,6 +39,11 @@
> > >  pub struct Flags(u32);
> > >
> > >  impl Flags {
> > > +    /// Get a flags value with all bits unset.
> > > +    pub fn empty() -> Self {
> > > +        Self(0)
> > > +    }
> >
> > No! Zero is not a reasonable default for GFP flags.
> 
> This is not a default.
> 
> > In fact, I don't know any
> > place in the kernel where we would want no reclaim + no IO + no FS without any
> > other flags (such as high-priority or kswapd can wake). Especially, because for
> > NOIO and NOFS, memalloc_noio_{save, restore} and memalloc_nofs_{save, restore}
> > guards should be used instead.
> >
> > You also don't seem to use this anywhere anyways.
> 
> This was used in an earlier iteration that included support for
> reservations. I used this value when fulfilling a reservation because
> it was an invariant of the API that no allocation would take place.
> 
> > Please also make sure to not bury such changes in unrelated other patches.
> 
> Thank you for spotting this errant change. Please consider whether it
> serves anyone's purpose to accuse someone of underhanded behavior.

As far as I can see I did not accuse anyone of underhanded behavior. But if it
came across this way to you, that wasn't the intention.

> 
> > > +/// The error returned by [`store`](Guard::store).
> > > +///
> > > +/// Contains the underlying error and the value that was not stored.
> > > +pub struct StoreError<T> {
> > > +    /// The error that occurred.
> > > +    pub error: Error,
> > > +    /// The value that was not stored.
> > > +    pub value: T,
> > > +}
> > > +
> > > +impl<T> From<StoreError<T>> for Error {
> > > +    fn from(value: StoreError<T>) -> Self {
> > > +        let StoreError { error, value: _ } = value;
> > > +        error
> >
> > Why not just `value.error`?
> 
> I prefer the clarity that this results in the value being dropped.

I don't think that any further clarity than the fact that value was passed by
value is needed.

Otherwise one could probably argue the same way for this:

fn from(value: StoreError<T>) -> Self {
   let error = value.error;
   drop(value);
   error
}

But that's up to you.

> Is there written guidance on this matter?

I don't think so.