Re: [PATCH v6 9/9] rust: sync: atomic: Add Atomic<{usize,isize}>

[Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

On Fri, Jul 11, 2025 at 11:00 AM Benno Lossin <lossin@kernel.org> wrote:
>
> Do we have a static assert with these cfgs that `isize` has the same
> size as these?
>
> If not, then it would probably make sense to add them now.

Yeah, according to e.g. Matthew et al., we may end up with 128-bit
pointers in the kernel fairly soon (e.g. a decade):

    https://lwn.net/Articles/908026/

I rescued part of what I wrote in the old `mod assumptions` which I
never got to send back then -- most of the `static_asserts` are
redundant now that we define directly the types in the `ffi` crate (I
mean, we could still assert that `size_of::<c_char>() == 1` and so on,
but they are essentially a tautology now), so I adapted the comments.
Please see below (draft).

Cheers,
Miguel

[-- Attachment #2: 0001-rust-ffi-assert-sizes-and-clarify-128-bit-situation.patch --]
[-- Type: text/x-patch, Size: 2026 bytes --]

From afd58f3808bd41cfb92bf1acdf2a19081a439ca3 Mon Sep 17 00:00:00 2001
From: Miguel Ojeda <ojeda@kernel.org>
Date: Fri, 11 Jul 2025 15:27:27 +0200
Subject: [PATCH] rust: ffi: assert sizes and clarify 128-bit situation

Link: https://lwn.net/Articles/908026/
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 rust/ffi.rs | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/rust/ffi.rs b/rust/ffi.rs
index d60aad792af4..bbda56c28ca8 100644
--- a/rust/ffi.rs
+++ b/rust/ffi.rs
@@ -38,11 +38,43 @@ macro_rules! alias {
 
     // In the kernel, `intptr_t` is defined to be `long` in all platforms, so we can map the type to
     // `isize`.
+    //
+    // It is likely that the assumption that `long` is the size of a CPU register/pointer will stay
+    // when support for 128-bit architectures is added, thus these will still mapped to `{i,u}size`.
     c_long = isize;
     c_ulong = usize;
 
+    // Since `long` will likely be 128-bit for 128-bit architectures, `long long` will likely be
+    // increased. Thus these may happen to be either 64-bit or 128-bit in the future, and thus new
+    // code should avoid relying on them being 64-bit.
     c_longlong = i64;
     c_ulonglong = u64;
 }
 
+// Thus, `long` may be 32-bit, 64-bit or 128-bit.
+const _: () = {
+    assert!(
+        core::mem::size_of::<c_long>()
+            == if cfg!(CONFIG_128BIT) {
+                core::mem::size_of::<u128>()
+            } else if cfg!(CONFIG_64BIT) {
+                core::mem::size_of::<u64>()
+            } else {
+                core::mem::size_of::<u32>()
+            }
+    );
+};
+
+// And `long long` may be 64-bit or 128-bit.
+const _: () = {
+    assert!(
+        core::mem::size_of::<c_longlong>()
+            == if cfg!(CONFIG_64BIT) {
+                core::mem::size_of::<u64>()
+            } else {
+                core::mem::size_of::<u128>()
+            }
+    );
+};
+
 pub use core::ffi::c_void;

base-commit: d7b8f8e20813f0179d8ef519541a3527e7661d3a
-- 
2.50.1