rust/kernel/alloc.rs | 8 ++++++++ rust/kernel/alloc/allocator.rs | 8 ++++++++ rust/kernel/alloc/kbox.rs | 13 +++++++++---- rust/kernel/sync/arc.rs | 6 +++--- 4 files changed, 28 insertions(+), 7 deletions(-)
The Rust bindings for XArray include a build-time check to ensure that
you can only use the XArray with pointers that are 4-byte aligned.
Because of that, there is currently a build failure if you attempt to
create an XArray<KBox<T>> where T is a 1-byte or 2-byte aligned type.
However, this error is incorrect as KBox<_> is guaranteed to be a
pointer that comes from kmalloc, and kmalloc always produces pointers
that are at least 4-byte aligned.
To fix this, we augment the compile-time logic that computes the
alignment of KBox<_> to take the minimum alignment of its allocator into
account.
Intended to land through alloc-next under the RUST [ALLOC] entry.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
Changes in v2:
- Reword guarantee on `const MIN_ALIGN`.
- Change formatting of if/else in kbox.rs.
- Rebase on v6.17-rc1.
- Link to v1: https://lore.kernel.org/r/20250715-align-min-allocator-v1-0-3e1b2a5516c0@google.com
---
Alice Ryhl (2):
rust: alloc: specify the minimum alignment of each allocator
rust: alloc: take the allocator into account for FOREIGN_ALIGN
rust/kernel/alloc.rs | 8 ++++++++
rust/kernel/alloc/allocator.rs | 8 ++++++++
rust/kernel/alloc/kbox.rs | 13 +++++++++----
rust/kernel/sync/arc.rs | 6 +++---
4 files changed, 28 insertions(+), 7 deletions(-)
---
base-commit: 062b3e4a1f880f104a8d4b90b767788786aa7b78
change-id: 20250715-align-min-allocator-b31aee53cbda
Best regards,
--
Alice Ryhl <aliceryhl@google.com>
On Mon Aug 11, 2025 at 2:31 PM CEST, Alice Ryhl wrote:
> Alice Ryhl (2):
> rust: alloc: specify the minimum alignment of each allocator
[ Add helper for ARCH_KMALLOC_MINALIGN; remove cast to usize. - Danilo ]
> rust: alloc: take the allocator into account for FOREIGN_ALIGN
Applied to alloc-next, thanks!
--
@Andrew: Just a heads-up, this has a minor conflict with your tree, which
should also show up in linux-next soon.
diff --cc rust/kernel/alloc.rs
index b39c279236f5,907301334d8c..000000000000
--- a/rust/kernel/alloc.rs
+++ b/rust/kernel/alloc.rs
@@@ -164,7 -137,15 +164,15 @@@ impl NumaNode
/// - Implementers must ensure that all trait functions abide by the guarantees documented in the
/// `# Guarantees` sections.
pub unsafe trait Allocator {
+ /// The minimum alignment satisfied by all allocations from this allocator.
+ ///
+ /// # Guarantees
+ ///
+ /// Any pointer allocated by this allocator is guaranteed to be aligned to `MIN_ALIGN` even if
+ /// the requested layout has a smaller alignment.
+ const MIN_ALIGN: usize;
+
- /// Allocate memory based on `layout` and `flags`.
+ /// Allocate memory based on `layout`, `flags` and `nid`.
///
/// On success, returns a buffer represented as `NonNull<[u8]>` that satisfies the layout
/// constraints (i.e. minimum size and alignment as specified by `layout`).
On Fri, Aug 15, 2025 at 9:12 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> diff --cc rust/kernel/alloc.rs
> index b39c279236f5,907301334d8c..000000000000
> --- a/rust/kernel/alloc.rs
> +++ b/rust/kernel/alloc.rs
> @@@ -164,7 -137,15 +164,15 @@@ impl NumaNode
> /// - Implementers must ensure that all trait functions abide by the guarantees documented in the
> /// `# Guarantees` sections.
> pub unsafe trait Allocator {
> + /// The minimum alignment satisfied by all allocations from this allocator.
> + ///
> + /// # Guarantees
> + ///
> + /// Any pointer allocated by this allocator is guaranteed to be aligned to `MIN_ALIGN` even if
> + /// the requested layout has a smaller alignment.
> + const MIN_ALIGN: usize;
> +
> - /// Allocate memory based on `layout` and `flags`.
> + /// Allocate memory based on `layout`, `flags` and `nid`.
> ///
> /// On success, returns a buffer represented as `NonNull<[u8]>` that satisfies the layout
> /// constraints (i.e. minimum size and alignment as specified by `layout`).
`MIN_ALIGN` is missing in `Cmalloc` -- from `rusttest`:
error[E0046]: not all trait items implemented, missing: `MIN_ALIGN`
--> rust/kernel/alloc/allocator_test.rs:48:1
|
48 | unsafe impl Allocator for Cmalloc {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `MIN_ALIGN` in
implementation
|
::: rust/kernel/alloc.rs:173:5
|
173 | const MIN_ALIGN: usize;
| ---------------------- `MIN_ALIGN` from trait
i.e. similar to the other one.
Cheers,
Miguel
On 15.08.25 21:12, Danilo Krummrich wrote:
> On Mon Aug 11, 2025 at 2:31 PM CEST, Alice Ryhl wrote:
>> Alice Ryhl (2):
>> rust: alloc: specify the minimum alignment of each allocator
>
> [ Add helper for ARCH_KMALLOC_MINALIGN; remove cast to usize. - Danilo ]
>
>> rust: alloc: take the allocator into account for FOREIGN_ALIGN
>
> Applied to alloc-next, thanks!
I had a build error with my daily linux-next builds for Fedora (using
the Fedora rawhide config) on arm64 (ppc64le and x86_64 worked fine).
From a quick look it seems it might be due to this series, which
turned up in -next today:
"""
error[E0428]: the name `ARCH_KMALLOC_MINALIGN` is defined multiple times
--> /builddir/build/BUILD/kernel-6.17.0-build/kernel-next-20250818/linux-6.17.0-0.0.next.20250818.423.vanilla.fc44.aarch64/rust/bindings/bindings_generated.rs:134545:1
|
9622 | pub const ARCH_KMALLOC_MINALIGN: u32 = 8;
| ----------------------------------------- previous definition of the value `ARCH_KMALLOC_MINALIGN` here
...
134545 | pub const ARCH_KMALLOC_MINALIGN: usize = 8;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `ARCH_KMALLOC_MINALIGN` redefined here
|
= note: `ARCH_KMALLOC_MINALIGN` must be defined only once in the value namespace of this module
error: aborting due to 1 previous error
For more information about this error, try `rustc --explain E0428`.
make[2]: *** [rust/Makefile:539: rust/bindings.o] Error 1
make[1]: *** [/builddir/build/BUILD/kernel-6.17.0-build/kernel-next-20250818/linux-6.17.0-0.0.next.20250818.423.vanilla.fc44.aarch64/Makefile:1294: prepare] Error 2
make: *** [Makefile:256: __sub-make] Error 2
"""
Full log:
https://download.copr.fedorainfracloud.org/results/@kernel-vanilla/next/fedora-rawhide-aarch64/09439461-next-next-all/builder-live.log.gz
Ciao, Thorsten
On Mon Aug 18, 2025 at 1:09 PM CEST, Thorsten Leemhuis wrote: > error[E0428]: the name `ARCH_KMALLOC_MINALIGN` is defined multiple times > --> /builddir/build/BUILD/kernel-6.17.0-build/kernel-next-20250818/linux-6.17.0-0.0.next.20250818.423.vanilla.fc44.aarch64/rust/bindings/bindings_generated.rs:134545:1 > | > 9622 | pub const ARCH_KMALLOC_MINALIGN: u32 = 8; > | ----------------------------------------- previous definition of the value `ARCH_KMALLOC_MINALIGN` here > ... > 134545 | pub const ARCH_KMALLOC_MINALIGN: usize = 8; > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `ARCH_KMALLOC_MINALIGN` redefined here > | > = note: `ARCH_KMALLOC_MINALIGN` must be defined only once in the value namespace of this module > > error: aborting due to 1 previous error Thanks for reporting, the diff below should fix it, I'll send a patch soon. diff --git a/rust/bindgen_parameters b/rust/bindgen_parameters index 0f96af8b9a7f..02b371b98b39 100644 --- a/rust/bindgen_parameters +++ b/rust/bindgen_parameters @@ -34,3 +34,4 @@ # We use const helpers to aid bindgen, to avoid conflicts when constants are # recognized, block generation of the non-helper constants. --blocklist-item ARCH_SLAB_MINALIGN +--blocklist-item ARCH_KMALLOC_MINALIGN
On Mon, Aug 18, 2025 at 1:09 PM Thorsten Leemhuis <linux@leemhuis.info> wrote: > > on arm64 (ppc64le and x86_64 worked fine). Yeah, it happens in arm, arm64, loongarch64 and riscv64 -- we don't have powerpc support for Rust upstream yet (we had it originally out-of-tree, but it never got upstreamed). Cheers, Miguel
* Alice Ryhl <aliceryhl@google.com> [250811 08:32]: > The Rust bindings for XArray include a build-time check to ensure that > you can only use the XArray with pointers that are 4-byte aligned. > Because of that, there is currently a build failure if you attempt to > create an XArray<KBox<T>> where T is a 1-byte or 2-byte aligned type. > However, this error is incorrect as KBox<_> is guaranteed to be a > pointer that comes from kmalloc, and kmalloc always produces pointers > that are at least 4-byte aligned. > > To fix this, we augment the compile-time logic that computes the > alignment of KBox<_> to take the minimum alignment of its allocator into > account. > > Intended to land through alloc-next under the RUST [ALLOC] entry. > > Signed-off-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Liam R. Howlett <Liam.Howlett@oracle.com> > --- > Changes in v2: > - Reword guarantee on `const MIN_ALIGN`. > - Change formatting of if/else in kbox.rs. > - Rebase on v6.17-rc1. > - Link to v1: https://lore.kernel.org/r/20250715-align-min-allocator-v1-0-3e1b2a5516c0@google.com > > --- > Alice Ryhl (2): > rust: alloc: specify the minimum alignment of each allocator > rust: alloc: take the allocator into account for FOREIGN_ALIGN > > rust/kernel/alloc.rs | 8 ++++++++ > rust/kernel/alloc/allocator.rs | 8 ++++++++ > rust/kernel/alloc/kbox.rs | 13 +++++++++---- > rust/kernel/sync/arc.rs | 6 +++--- > 4 files changed, 28 insertions(+), 7 deletions(-) > --- > base-commit: 062b3e4a1f880f104a8d4b90b767788786aa7b78 > change-id: 20250715-align-min-allocator-b31aee53cbda > > Best regards, > -- > Alice Ryhl <aliceryhl@google.com> >
"Alice Ryhl" <aliceryhl@google.com> writes: > The Rust bindings for XArray include a build-time check to ensure that > you can only use the XArray with pointers that are 4-byte aligned. > Because of that, there is currently a build failure if you attempt to > create an XArray<KBox<T>> where T is a 1-byte or 2-byte aligned type. > However, this error is incorrect as KBox<_> is guaranteed to be a > pointer that comes from kmalloc, and kmalloc always produces pointers > that are at least 4-byte aligned. > > To fix this, we augment the compile-time logic that computes the > alignment of KBox<_> to take the minimum alignment of its allocator into > account. > > Intended to land through alloc-next under the RUST [ALLOC] entry. > > Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Best regards, Andreas Hindborg
© 2016 - 2025 Red Hat, Inc.