[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240908091905.1592e819@eugeo>
Date: Sun, 8 Sep 2024 09:19:05 +0200
From: Gary Guo <gary@...yguo.net>
To: David Gow <davidgow@...gle.com>
Cc: Andreas Hindborg <a.hindborg@...sung.com>, Boqun Feng
<boqun.feng@...il.com>, Miguel Ojeda <ojeda@...nel.org>, Jens Axboe
<axboe@...nel.dk>, Wedson Almeida Filho <wedsonaf@...il.com>,
linux-block@...r.kernel.org, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-um@...ts.infradead.org
Subject: Re: [RFC PATCH] rust: block: Use 32-bit atomics
On Thu, 5 Sep 2024 14:12:14 +0800
David Gow <davidgow@...gle.com> wrote:
> Not all architectures have core::sync::atomic::AtomicU64 available. In
> particular, 32-bit x86 doesn't support it. AtomicU32 is available
> everywhere, so use that instead.
Switching to 32-bit directly makes it vulnerable to counter overflow
issue. If 32-bit atomics are to be used for this, saturation logic must
be implemented to deal with it.
Ideally we should just use `refcount_t` instead of custom atomic ops.
Although it appears that the rust block driver needs a cmpxchg which
refcount_t doesn't provide.
>
> Hopefully we can add AtomicU64 to Rust-for-Linux more broadly, so this
> won't be an issue, but it's not supported in core from upstream Rust:
> https://doc.rust-lang.org/std/sync/atomic/#portability
Kernel has a 64-bit atomic implementation which is backed by spinlocks
if the architecture doesn't support it. Although, I think for the
purpose in rust block, it's unlikely to be necessary.
Best,
Gary
>
> This can be tested on 32-bit x86 UML via:
> ./tools/testing/kunit/kunit.py run --make_options LLVM=1 --kconfig_add CONFIG_RUST=y --kconfig_add CONFIG_64BIT=n --kconfig_add CONFIG_FORTIFY_SOURCE=n
>
> Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module")
> Signed-off-by: David Gow <davidgow@...gle.com>
> ---
>
> Hi all,
>
> I encountered this build error with Rust/UML since the kernel::block::mq
> stuff landed. I'm not 100% sure just swapping AtomicU64 with AtomicU32
> is correct -- please correct me if not -- but this does at least get the
> Rust/UML/x86-32 builds here compiling and running again.
>
> (And gives me more encouragement to go to the Rust atomics talk at
> Plumbers.)
>
> Cheers,
> -- David
>
> ---
> rust/kernel/block/mq/operations.rs | 4 ++--
> rust/kernel/block/mq/request.rs | 12 ++++++------
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/rust/kernel/block/mq/operations.rs b/rust/kernel/block/mq/operations.rs
> index 9ba7fdfeb4b2..c31c36af6bc4 100644
> --- a/rust/kernel/block/mq/operations.rs
> +++ b/rust/kernel/block/mq/operations.rs
> @@ -11,7 +11,7 @@
> error::{from_result, Result},
> types::ARef,
> };
> -use core::{marker::PhantomData, sync::atomic::AtomicU64, sync::atomic::Ordering};
> +use core::{marker::PhantomData, sync::atomic::AtomicU32, sync::atomic::Ordering};
>
> /// Implement this trait to interface blk-mq as block devices.
> ///
> @@ -186,7 +186,7 @@ impl<T: Operations> OperationsVTable<T> {
>
> // SAFETY: The refcount field is allocated but not initialized, so
> // it is valid for writes.
> - unsafe { RequestDataWrapper::refcount_ptr(pdu.as_ptr()).write(AtomicU64::new(0)) };
> + unsafe { RequestDataWrapper::refcount_ptr(pdu.as_ptr()).write(AtomicU32::new(0)) };
>
> Ok(0)
> })
> diff --git a/rust/kernel/block/mq/request.rs b/rust/kernel/block/mq/request.rs
> index a0e22827f3f4..418256dcd45b 100644
> --- a/rust/kernel/block/mq/request.rs
> +++ b/rust/kernel/block/mq/request.rs
> @@ -13,7 +13,7 @@
> use core::{
> marker::PhantomData,
> ptr::{addr_of_mut, NonNull},
> - sync::atomic::{AtomicU64, Ordering},
> + sync::atomic::{AtomicU32, Ordering},
Powered by blists - more mailing lists