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: <Z7MfETop-rGSNLFo@cassiopeiae>
Date: Mon, 17 Feb 2025 12:35:45 +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 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. 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.

Please also make sure to not bury such changes in unrelated other patches.

> +/// 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`?