From: Gary Guo <gary@garyguo.net>
To: David Gow <davidgow@google.com>
Cc: Andreas Hindborg <a.hindborg@samsung.com>,
Boqun Feng <boqun.feng@gmail.com>,
Miguel Ojeda <ojeda@kernel.org>, Jens Axboe <axboe@kernel.dk>,
Wedson Almeida Filho <wedsonaf@gmail.com>,
linux-block@vger.kernel.org, rust-for-linux@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-um@lists.infradead.org
Subject: Re: [RFC PATCH] rust: block: Use 32-bit atomics
Date: Sun, 8 Sep 2024 09:19:05 +0200 [thread overview]
Message-ID: <20240908091905.1592e819@eugeo> (raw)
In-Reply-To: <20240905061214.3954271-1-davidgow@google.com>
On Thu, 5 Sep 2024 14:12:14 +0800
David Gow <davidgow@google.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@google.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},
prev parent reply other threads:[~2024-09-08 7:19 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-05 6:12 [RFC PATCH] rust: block: Use 32-bit atomics David Gow
2024-09-05 7:52 ` Alice Ryhl
2024-09-08 7:19 ` Gary Guo [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240908091905.1592e819@eugeo \
--to=gary@garyguo.net \
--cc=a.hindborg@samsung.com \
--cc=axboe@kernel.dk \
--cc=boqun.feng@gmail.com \
--cc=davidgow@google.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=wedsonaf@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.