Re: [PATCH] rust: add `CacheAligned` for easy cache line alignment of values

[Andreas Hindborg <a.hindborg@kernel.org>]

"Gary Guo" <gary@garyguo.net> writes:

> On Wed Jan 28, 2026 at 2:25 PM GMT, Alexandre Courbot wrote:
>> On Wed Jan 28, 2026 at 11:05 PM JST, Andreas Hindborg wrote:
>>> `CacheAligned` allows to easily align values to a 64 byte boundary.
>>>
>>> An example use case is the kernel `struct spinlock`. This struct is 4 bytes
>>> on x86 when lockdep is not enabled. The structure is not padded to fit a
>>> cache line. The effect of this for `SpinLock` is that the lock variable and
>>> the value protected by the lock might share a cache line, depending on the
>>> alignment requirements of the protected value. Wrapping the value in
>>> `CacheAligned` to get a `SpinLock<CacheAligned<T>>` solves this problem.
>>>
>>> Signed-off-by: Andreas Hindborg <a.hindborg@samsung.com>
>>> ---
>>> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
>>> ---
>>>  rust/kernel/cache_aligned.rs | 59 ++++++++++++++++++++++++++++++++++++++++++++
>>>  rust/kernel/lib.rs           |  2 ++
>>>  2 files changed, 61 insertions(+)
>>>
>>> diff --git a/rust/kernel/cache_aligned.rs b/rust/kernel/cache_aligned.rs
>>> new file mode 100644
>>> index 0000000000000..9c33b8613c077
>>> --- /dev/null
>>> +++ b/rust/kernel/cache_aligned.rs
>>> @@ -0,0 +1,59 @@
>>> +// SPDX-License-Identifier: GPL-2.0
>>> +
>>> +use kernel::try_pin_init;
>>> +use pin_init::{
>>> +    pin_data,
>>> +    pin_init,
>>> +    PinInit, //
>>> +};
>>> +
>>> +/// Wrapper type that alings content to a 64 byte cache line.
>>
>> nit: s/alings/aligns
>>
>>> +#[repr(align(64))]
>>
>> While 64 bytes is the most common cache line size, AFAIK this is not
>> a universal value? Can we expose and use `L1_CACHE_BYTES` here?
>
> Unfortunately `repr(align())` does not accept expression or macro invocations.
> It's still possible with code-generation, but it'll be more tricky.
>
> On all archs that we do support today, I think the value is always 64. However
> it'd worth putting a FIXME or TODO (or assertion, maybe?) in case new archs gets
> addded where this isn't true.

I was looking into how to implement this properly. Apparently, we don't
have a config item that specifies the L1 cache line size for all
architectures. Each architectures defines the cache line size as C
define in a header. For x86 we have

  #define L1_CACHE_SHIFT	(CONFIG_X86_L1_CACHE_SHIFT)

and for arm64

  #define L1_CACHE_SHIFT		(6)

and so on.

One thing we could do is run the C preprocessor on a small snippet to
expand the `L1_CACHE_SHIFT` symbol at some point before invoking
`rustc`. Then we can pass the value to `rustc` via environment variable
when building the `macros` crate. This is similar to how we pass
`RUST_MODFILE` to `rustc`, sans the cpp invocation.

Otherwise we have to convince all architectures that support Rust to
emit a config that we can rely on, like `CONFIG_L1_CACHE_SHIFT`.

The latter options is probably the better one, what do you all think?

Best regards,
Andreas Hindborg