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

[Gary Guo]

On Mon May 18, 2026 at 2:41 PM BST, Andreas Hindborg wrote:
> "Gary Guo" <gary@xxxxxxxxxxx> 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@xxxxxxxxxxx>
>>>> ---
>>>> Signed-off-by: Andreas Hindborg <a.hindborg@xxxxxxxxxx>
>>>> ---
>>>>  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

You can implement this with generics alone using associative types.

mod sealed {
    pub trait Sealed {
        type Repr;
    }
}

trait Alignment: sealed::Sealed {}

#[repr(transparent)]
struct Align<const N: usize>([<Self as sealed::Sealed>::Repr; 0])
where
    Self: Alignment;

impl<const N: usize> Align<N>
where
    Self: Alignment,
{
    #[inline]
    pub fn new() -> Self {
        Align([])
    }
}

macro_rules! impl_align {
    () => {};
    ($a:literal $($rest:literal)*) => {
        const _: () = {
            #[repr(align($a))]
            struct Repr;

            impl sealed::Sealed for Align<$a> {
                type Repr = Repr;
            }
            
            impl Alignment for Align<$a> {}
        };
        
        impl_align!($($rest)*);
    }
}

impl_align!(32 64 128 256);

Best,
Gary