rust: kbuild: Don't export __pfx symbols

With CONFIG_PREFIX_SYMBOLS, objtool adds __pfx prefix symbols
to claim the compiler emitted call padding bytes. When
CONFIG_X86_KERNEL_IBT is not selected, t

rust: kbuild: Don't export __pfx symbols

With CONFIG_PREFIX_SYMBOLS, objtool adds __pfx prefix symbols
to claim the compiler emitted call padding bytes. When
CONFIG_X86_KERNEL_IBT is not selected, the symbols are added to
individual object files and for Rust objects, they end up being
exported, resulting in warnings with CONFIG_GENDWARFKSYMS as the
symbols have no debugging information:

warning: gendwarfksyms: symbol_print_versions: no information for symbol __pfx_rust_helper_put_task_struct
warning: gendwarfksyms: symbol_print_versions: no information for symbol __pfx_rust_helper_task_euid
warning: gendwarfksyms: symbol_print_versions: no information for symbol __pfx_rust_helper_readq_relaxed
...

Filter out the __pfx prefix from exported symbols similarly to
the existing __cfi and __odr_asan prefixes.

Signed-off-by: Sami Tolvanen <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Cc: [email protected]
Fixes: ac61506bf2d1 ("rust: Use gendwarfksyms + extended modversions for CONFIG_MODVERSIONS")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: Fix enabling Rust and building with GCC for LoongArch

This patch fixes a build issue on LoongArch when Rust is enabled and
compiled with GCC by explicitly setting the bindgen target and skippi

rust: Fix enabling Rust and building with GCC for LoongArch

This patch fixes a build issue on LoongArch when Rust is enabled and
compiled with GCC by explicitly setting the bindgen target and skipping
C flags that Clang doesn't support.

Cc: [email protected]
Acked-by: Miguel Ojeda <[email protected]>
Signed-off-by: WANG Rui <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

ARM: 9441/1: rust: Enable Rust support for ARMv7

This commit allows building ARMv7 kernels with Rust support.

The rust core library expects some __eabi_... functions
that are not implemented in the

ARM: 9441/1: rust: Enable Rust support for ARMv7

This commit allows building ARMv7 kernels with Rust support.

The rust core library expects some __eabi_... functions
that are not implemented in the kernel.
Those functions are some float operations and __aeabi_uldivmod.
For now those are implemented with define_panicking_intrinsics!.

This is based on the code by Sven Van Asbroeck from the original
rust branch and inspired by the AArch version by Jamie Cunliffe.

I have tested the rust samples and a custom simple MMIO module
on hardware (De1SoC FPGA + Arm A9 CPU).

Tested-by: Rudraksha Gupta <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Acked-by: Miguel Ojeda <[email protected]>
Tested-by: Miguel Ojeda <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Signed-off-by: Christian Schrefl <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...

rust: kbuild: skip `--remap-path-prefix` for `rustdoc`

`rustdoc` only recognizes `--remap-path-prefix` starting with
Rust 1.81.0, which is later than on minimum, so we cannot pass it
unconditionally

rust: kbuild: skip `--remap-path-prefix` for `rustdoc`

`rustdoc` only recognizes `--remap-path-prefix` starting with
Rust 1.81.0, which is later than on minimum, so we cannot pass it
unconditionally. Otherwise, we get:

error: Unrecognized option: 'remap-path-prefix'

Note that `rustc` (the compiler) does recognize the flag since a long
time ago (1.26.0).

Moreover, `rustdoc` since Rust 1.82.0 ICEs in out-of-tree builds when
using `--remap-path-prefix`. The issue has been reduced and reported
upstream [1].

Thus workaround both issues by simply skipping the flag when generating
the docs -- it is not critical there anyway.

The ICE does not reproduce under `--test`, but we still need to skip
the flag as well for `RUSTDOC TK` since it is not recognized.

Fixes: dbdffaf50ff9 ("kbuild, rust: use -fremap-path-prefix to make paths relative")
Link: https://github.com/rust-lang/rust/issues/138520 [1]
Signed-off-by: Miguel Ojeda <[email protected]>
Reviewed-by: Tamir Duberstein <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

rust: pass correct target to bindgen on Usermode Linux

Usermode Linux uses "um" as primary architecture name and the underlying
physical architecture is provided in "SUBARCH".

Resolve the target ar

rust: pass correct target to bindgen on Usermode Linux

Usermode Linux uses "um" as primary architecture name and the underlying
physical architecture is provided in "SUBARCH".

Resolve the target architecture flags through that underlying
architecture.

This is the same pattern as used by scripts/Makefile.clang from which
the bindgen flags are derived.

[ David says:

(...) this is enough to get Rust-for-Linux working with gcc under
64-bit UML on my system.

- Miguel ]

Signed-off-by: Thomas Weißschuh <[email protected]>
Reviewed-by: David Gow <[email protected]>
Acked-by: Johannes Berg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: pin-init: add `std` and `alloc` support from the user-space version

To synchronize the kernel's version of pin-init with the user-space
version, introduce support for `std` and `alloc`. While

rust: pin-init: add `std` and `alloc` support from the user-space version

To synchronize the kernel's version of pin-init with the user-space
version, introduce support for `std` and `alloc`. While the kernel uses
neither, the user-space version has to support both. Thus include the
required `#[cfg]`s and additional code.

Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Fiona Behrens <[email protected]>
Tested-by: Andreas Hindborg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Undo the temporary `--extern force:alloc` since now we have contents
for `alloc` here. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: make pin-init its own crate

Rename relative paths inside of the crate to still refer to the same
items, also rename paths inside of the kernel crate and adjust the build
system to build the cr

rust: make pin-init its own crate

Rename relative paths inside of the crate to still refer to the same
items, also rename paths inside of the kernel crate and adjust the build
system to build the crate.

[ Remove the `expect` (and thus the `lint_reasons` feature) since
the tree now uses `quote!` from `rust/macros/export.rs`. Remove the
`TokenStream` import removal, since it is now used as well.

In addition, temporarily (i.e. just for this commit) use an `--extern
force:alloc` to prevent an unknown `new_uninit` error in the `rustdoc`
target. For context, please see a similar case in:

https://lore.kernel.org/lkml/[email protected]/

And adjusted the message above. - Miguel ]

Signed-off-by: Benno Lossin <[email protected]>
Reviewed-by: Fiona Behrens <[email protected]>
Tested-by: Andreas Hindborg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: add pin-init crate build infrastructure

Add infrastructure for moving the initialization API to its own crate.
Covers all make targets such as `rust-analyzer` and `rustdoc`. The tests
of pin-i

rust: add pin-init crate build infrastructure

Add infrastructure for moving the initialization API to its own crate.
Covers all make targets such as `rust-analyzer` and `rustdoc`. The tests
of pin-init are not added to `rusttest`, as they are already tested in
the user-space repository [1].

Link: https://github.com/Rust-for-Linux/pin-init [1]
Co-developed-by: Benno Lossin <[email protected]>
Signed-off-by: Benno Lossin <[email protected]>
Tested-by: Andreas Hindborg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: kbuild: do not export generated KASAN ODR symbols

ASAN generates special synthetic symbols to help check for ODR
violations. These synthetic symbols lack debug information, so
gendwarfksyms em

rust: kbuild: do not export generated KASAN ODR symbols

ASAN generates special synthetic symbols to help check for ODR
violations. These synthetic symbols lack debug information, so
gendwarfksyms emits warnings when processing them. No code should ever
have a dependency on these symbols, so we should not be exporting them,
just like the __cfi symbols.

Signed-off-by: Matthew Maurer <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Fixed typo in commit message. Slightly reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: kbuild: add -fzero-init-padding-bits to bindgen_skip_cflags

This seems to break the build when building with gcc15:

Unable to generate bindings: ClangDiagnostic("error: unknown
argume

rust: kbuild: add -fzero-init-padding-bits to bindgen_skip_cflags

This seems to break the build when building with gcc15:

Unable to generate bindings: ClangDiagnostic("error: unknown
argument: '-fzero-init-padding-bits=all'\n")

Thus skip that flag.

Signed-off-by: Justin M. Forbes <[email protected]>
Fixes: dce4aab8441d ("kbuild: Use -fzero-init-padding-bits=all")
Reviewed-by: Kees Cook <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Slightly reworded commit. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: kbuild: use host dylib naming in rusttestlib-kernel

There seems to have been merge skew between commit b2c261fa8629 ("rust:
kbuild: expand rusttest target for macros") and commit 0730422bced5

rust: kbuild: use host dylib naming in rusttestlib-kernel

There seems to have been merge skew between commit b2c261fa8629 ("rust:
kbuild: expand rusttest target for macros") and commit 0730422bced5
("rust: use host dylib naming convention to support macOS") ; the latter
replaced `libmacros.so` with `$(libmacros_name)` and the former added an
instance of `libmacros.so`. The former was not yet applied when the
latter was sent, resulting in a stray `libmacros.so`. Replace the stray
with `$(libmacros_name)` to allow `rusttest` to build on macOS.

Fixes: 0730422bced5 ("rust: use host dylib naming convention to support macOS")
Signed-off-by: Tamir Duberstein <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Slightly reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: Use gendwarfksyms + extended modversions for CONFIG_MODVERSIONS

Previously, two things stopped Rust from using MODVERSIONS:
1. Rust symbols are occasionally too long to be represented in the

rust: Use gendwarfksyms + extended modversions for CONFIG_MODVERSIONS

Previously, two things stopped Rust from using MODVERSIONS:
1. Rust symbols are occasionally too long to be represented in the
original versions table
2. Rust types cannot be properly hashed by the existing genksyms
approach because:
* Looking up type definitions in Rust is more complex than C
* Type layout is potentially dependent on the compiler in Rust,
not just the source type declaration.

CONFIG_EXTENDED_MODVERSIONS addresses the first point, and
CONFIG_GENDWARFKSYMS the second. If Rust wants to use MODVERSIONS, allow
it to do so by selecting both features.

Signed-off-by: Sami Tolvanen <[email protected]>
Co-developed-by: Matthew Maurer <[email protected]>
Signed-off-by: Matthew Maurer <[email protected]>
Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

kbuild: rust: add PROCMACROLDFLAGS

These are flags to be passed when linking proc macros for the Rust
toolchain. If unset, it defaults to $(KBUILD_HOSTLDFLAGS).

This is needed because the list of f

kbuild: rust: add PROCMACROLDFLAGS

These are flags to be passed when linking proc macros for the Rust
toolchain. If unset, it defaults to $(KBUILD_HOSTLDFLAGS).

This is needed because the list of flags to link hostprogs is not
necessarily the same as the list of flags used to link libmacros.so.
When we build proc macros, we need the latter, not the former (e.g. when
using a Rust compiler binary linked to a different C library than host
programs).

To distinguish between the two, introduce this new variable to stand
out from KBUILD_HOSTLDFLAGS used to link other host progs.

Signed-off-by: HONG Yifan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ v3:

- `export`ed the variable. Otherwise it would not be visible in
`rust/Makefile`.

- Removed "additional" from the documentation and commit message,
since this actually replaces the other flags, unlike other cases.

- Added example of use case to documentation and commit message.
Thanks Alice for the details on what Google needs!

- Instead of `HOSTLDFLAGS`, used `KBUILD_HOSTLDFLAGS` as the fallback
to preserve the previous behavior as much as possible, as discussed
with Alice/Yifan. Thus moved the variable down too (currently we
do not modify `KBUILD_HOSTLDFLAGS` elsewhere) and avoided
mentioning `HOSTLDFLAGS` directly in the documentation.

- Fixed documentation header formatting.

- Reworded slightly.

- Miguel ]
Tested-by: Alice Ryhl <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Reviewed-by: HONG Yifan <[email protected]>
Acked-by: Masahiro Yamada <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: use host dylib naming convention to support macOS

Because the `macros` crate exposes procedural macros, it must be
compiled as a dynamic library (so it can be loaded by the compiler at
compile

rust: use host dylib naming convention to support macOS

Because the `macros` crate exposes procedural macros, it must be
compiled as a dynamic library (so it can be loaded by the compiler at
compile-time).

Before this change the resulting artifact was always named
`libmacros.so`, which works on hosts where this matches the naming
convention for dynamic libraries. However the proper name on macOS would
be `libmacros.dylib`.

This turns out to matter even when the dependency is passed with a path
(`--extern macros=path/to/libmacros.so` rather than `--extern macros`)
because rustc uses the file name to infer the type of the library (see
link). This is because there's no way to specify both the path to and
the type of the external library via CLI flags. The compiler could
speculatively parse the file to determine its type, but it does not do
so today.

This means that libraries that match neither rustc's naming convention
for static libraries nor the platform's naming convention for dynamic
libraries are *rejected*.

The only solution I've found is to follow the host platform's naming
convention. This patch does that by querying the compiler to determine
the appropriate name for the artifact. This allows the kernel to build
with CONFIG_RUST=y on macOS.

Link: https://github.com/rust-lang/rust/blob/d829780/compiler/rustc_metadata/src/locator.rs#L728-L752
Tested-by: Daniel Gomez <[email protected]>
Co-developed-by: Fiona Behrens <[email protected]>
Signed-off-by: Fiona Behrens <[email protected]>
Signed-off-by: Tamir Duberstein <[email protected]>
Tested-by: Andreas Hindborg <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Added `MAKEFLAGS=`s to avoid jobserver warnings. Removed space.
Reworded title. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: kbuild: run Clippy for `rusttest` code

Running Clippy for `rusttest` code is useful to catch issues there too,
even if the code is not as critical. In the future, this code may also
run in ker

rust: kbuild: run Clippy for `rusttest` code

Running Clippy for `rusttest` code is useful to catch issues there too,
even if the code is not as critical. In the future, this code may also
run in kernelspace and could be copy-pasted. Thus it is useful to keep
it under the same standards. For instance, it will now make us add
`// SAFETY` comments.

It also makes everything more consistent.

Thus clean the few issues spotted by Clippy and start running it.

Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: kbuild: set `bindgen`'s Rust target version

Each `bindgen` release may upgrade the list of Rust targets. For instance,
currently, in their master branch [1], the latest ones are:

Nightly

rust: kbuild: set `bindgen`'s Rust target version

Each `bindgen` release may upgrade the list of Rust targets. For instance,
currently, in their master branch [1], the latest ones are:

Nightly => {
vectorcall_abi: #124485,
ptr_metadata: #81513,
layout_for_ptr: #69835,
},
Stable_1_77(77) => { offset_of: #106655 },
Stable_1_73(73) => { thiscall_abi: #42202 },
Stable_1_71(71) => { c_unwind_abi: #106075 },
Stable_1_68(68) => { abi_efiapi: #105795 },

By default, the highest stable release in their list is used, and users
are expected to set one if they need to support older Rust versions
(e.g. see [2]).

Thus, over time, new Rust features are used by default, and at some
point, it is likely that `bindgen` will emit Rust code that requires a
Rust version higher than our minimum (or perhaps enabling an unstable
feature). Currently, there is no problem because the maximum they have,
as seen above, is Rust 1.77.0, and our current minimum is Rust 1.78.0.

Therefore, set a Rust target explicitly now to prevent going forward in
time too much and thus getting potential build failures at some point.

Since we also support a minimum `bindgen` version, and since `bindgen`
does not support passing unknown Rust target versions, we need to use
the list of our minimum `bindgen` version, rather than the latest. So,
since `bindgen` 0.65.1 had this list [3], we need to use Rust 1.68.0:

/// Rust stable 1.64
/// * `core_ffi_c` ([Tracking issue](https://github.com/rust-lang/rust/issues/94501))
=> Stable_1_64 => 1.64;
/// Rust stable 1.68
/// * `abi_efiapi` calling convention ([Tracking issue](https://github.com/rust-lang/rust/issues/65815))
=> Stable_1_68 => 1.68;
/// Nightly rust
/// * `thiscall` calling convention ([Tracking issue](https://github.com/rust-lang/rust/issues/42202))
/// * `vectorcall` calling convention (no tracking issue)
/// * `c_unwind` calling convention ([Tracking issue](https://github.com/rust-lang/rust/issues/74990))
=> Nightly => nightly;

...

/// Latest stable release of Rust
pub const LATEST_STABLE_RUST: RustTarget = RustTarget::Stable_1_68;

Thus add the `--rust-target 1.68` parameter. Add a comment as well
explaining this.

An alternative would be to use the currently running (i.e. actual) `rustc`
and `bindgen` versions to pick a "better" Rust target version. However,
that would introduce more moving parts depending on the user setup and
is also more complex to implement.

Starting with `bindgen` 0.71.0 [4], we will be able to set any future
Rust version instead, i.e. we will be able to set here our minimum
supported Rust version. Christian implemented it [5] after seeing this
patch. Thanks!

Cc: Christian Poveda <[email protected]>
Cc: Emilio Cobos Álvarez <[email protected]>
Cc: [email protected] # needed for 6.12.y; unneeded for 6.6.y; do not apply to 6.1.y
Fixes: c844fa64a2d4 ("rust: start supporting several `bindgen` versions")
Link: https://github.com/rust-lang/rust-bindgen/blob/21c60f473f4e824d4aa9b2b508056320d474b110/bindgen/features.rs#L97-L105 [1]
Link: https://github.com/rust-lang/rust-bindgen/issues/2960 [2]
Link: https://github.com/rust-lang/rust-bindgen/blob/7d243056d335fdc4537f7bca73c06d01aae24ddc/bindgen/features.rs#L131-L150 [3]
Link: https://github.com/rust-lang/rust-bindgen/blob/main/CHANGELOG.md#0710-2024-12-06 [4]
Link: https://github.com/rust-lang/rust-bindgen/pull/2993 [5]
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

kbuild: change working directory to external module directory with M=

Currently, Kbuild always operates in the output directory of the kernel,
even when building external modules. This increases the

kbuild: change working directory to external module directory with M=

Currently, Kbuild always operates in the output directory of the kernel,
even when building external modules. This increases the risk of external
module Makefiles attempting to write to the kernel directory.

This commit switches the working directory to the external module
directory, allowing the removal of the $(KBUILD_EXTMOD)/ prefix from
some build artifacts.

The command for building external modules maintains backward
compatibility, but Makefiles that rely on working in the kernel
directory may break. In such cases, $(objtree) and $(srctree) should
be used to refer to the output and source directories of the kernel.

The appearance of the build log will change as follows:

[Before]

$ make -C /path/to/my/linux M=/path/to/my/externel/module
make: Entering directory '/path/to/my/linux'
CC [M] /path/to/my/externel/module/helloworld.o
MODPOST /path/to/my/externel/module/Module.symvers
CC [M] /path/to/my/externel/module/helloworld.mod.o
CC [M] /path/to/my/externel/module/.module-common.o
LD [M] /path/to/my/externel/module/helloworld.ko
make: Leaving directory '/path/to/my/linux'

[After]

$ make -C /path/to/my/linux M=/path/to/my/externel/module
make: Entering directory '/path/to/my/linux'
make[1]: Entering directory '/path/to/my/externel/module'
CC [M] helloworld.o
MODPOST Module.symvers
CC [M] helloworld.mod.o
CC [M] .module-common.o
LD [M] helloworld.ko
make[1]: Leaving directory '/path/to/my/externel/module'
make: Leaving directory '/path/to/my/linux'

Printing "Entering directory" twice is cumbersome. This will be
addressed later.

Signed-off-by: Masahiro Yamada <[email protected]>
Reviewed-by: Nicolas Schier <[email protected]>

show more ...

rust: jump_label: skip formatting generated file

After a source tree build of the kernel, and having used the `RSCPP`
rule, running `rustfmt` fails with:

error: macros that expand to items must

rust: jump_label: skip formatting generated file

After a source tree build of the kernel, and having used the `RSCPP`
rule, running `rustfmt` fails with:

error: macros that expand to items must be delimited with braces or followed by a semicolon
--> rust/kernel/arch_static_branch_asm.rs:1:27
|
1 | ...ls!("1: jmp " ... ".popsection \n\t")
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
help: change the delimiters to curly braces
|
1 | ::kernel::concat_literals!{"1: jmp " ... ".popsection \n\t"}
| ~ ~
help: add a semicolon
|
1 | ::kernel::concat_literals!("1: jmp " ... ".popsection \n\t");
| +

This file is not meant to be formatted nor works on its own since it is
meant to be textually included.

Thus skip formatting it by prefixing its name with `generated_`.

Cc: Masami Hiramatsu <[email protected]>
Cc: Alex Gaynor <[email protected]>
Cc: Mathieu Desnoyers <[email protected]>
Cc: Boqun Feng <[email protected]>
Cc: Gary Guo <[email protected]>
Cc: Björn Roy Baron <[email protected]>
Cc: Benno Lossin <[email protected]>
Cc: Andreas Hindborg <[email protected]>
Cc: Alice Ryhl <[email protected]>
Cc: Trevor Gross <[email protected]>
Link: https://lore.kernel.org/[email protected]
Fixes: 169484ab6677 ("rust: add arch_static_branch")
Signed-off-by: Miguel Ojeda <[email protected]>
Signed-off-by: Steven Rostedt (Google) <[email protected]>

show more ...

rust: use custom FFI integer types

Currently FFI integer types are defined in libcore. This commit creates
the `ffi` crate and asks bindgen to use that crate for FFI integer types
instead of `core::

rust: use custom FFI integer types

Currently FFI integer types are defined in libcore. This commit creates
the `ffi` crate and asks bindgen to use that crate for FFI integer types
instead of `core::ffi`.

This commit is preparatory and no type changes are made in this commit
yet.

Signed-off-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Added `rustdoc`, `rusttest` and KUnit tests support. Rebased on top of
`rust-next` (e.g. migrated more `core::ffi` cases). Reworded crate
docs slightly and formatted. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: fix size_t in bindgen prototypes of C builtins

Without `-fno-builtin`, for functions like memcpy/memmove (and many
others), bindgen seems to be using the clang-provided prototype. This
prototy

rust: fix size_t in bindgen prototypes of C builtins

Without `-fno-builtin`, for functions like memcpy/memmove (and many
others), bindgen seems to be using the clang-provided prototype. This
prototype is ABI-wise compatible, but the issue is that it does not have
the same information as the source code w.r.t. typedefs.

For example, bindgen generates the following:

extern "C" {
pub fn strlen(s: *const core::ffi::c_char) -> core::ffi::c_ulong;
}

note that the return type is `c_ulong` (i.e. unsigned long), despite the
size_t-is-usize behavior (this is default, and we have not opted out
from it using --no-size_t-is-usize).

Similarly, memchr's size argument should be of type `__kernel_size_t`,
but bindgen generates `c_ulong` directly.

We want to ensure any `size_t` is translated to Rust `usize` so that we
can avoid having them be different type on 32-bit and 64-bit
architectures, and hence would require a lot of excessive type casts
when calling FFI functions.

I found that this bindgen behavior (which probably is caused by
libclang) can be disabled by `-fno-builtin`. Using the flag for compiled
code can result in less optimisation because compiler cannot assume
about their properties anymore, but this should not affect bindgen.

[ Trevor asked: "I wonder how reliable this behavior is. Maybe bindgen
could do a better job controlling this, is there an open issue?".

Gary replied: ..."apparently this is indeed the suggested approach in
https://github.com/rust-lang/rust-bindgen/issues/1770". - Miguel ]

Signed-off-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[ Formatted comment. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: add arch_static_branch

To allow the Rust implementation of static_key_false to use runtime code
patching instead of the generic implementation, pull in the relevant
inline assembly from the ju

rust: add arch_static_branch

To allow the Rust implementation of static_key_false to use runtime code
patching instead of the generic implementation, pull in the relevant
inline assembly from the jump_label.h header by running the C
preprocessor on a .rs.S file. Build rules are added for .rs.S files.

Since the relevant inline asm has been adjusted to export the inline asm
via the ARCH_STATIC_BRANCH_ASM macro in a consistent way, the Rust side
does not need architecture specific code to pull in the asm.

It is not possible to use the existing C implementation of
arch_static_branch via a Rust helper because it passes the argument
`key` to inline assembly as an 'i' parameter. Any attempt to add a C
helper for this function will fail to compile because the value of `key`
must be known at compile-time.

Cc: Masami Hiramatsu <[email protected]>
Cc: Mathieu Desnoyers <[email protected]>
Cc: Josh Poimboeuf <[email protected]>
Cc: Jason Baron <[email protected]>
Cc: Ard Biesheuvel <[email protected]>
Cc: Alex Gaynor <[email protected]>
Cc: Wedson Almeida Filho <[email protected]>
Cc: Gary Guo <[email protected]>
Cc: " =?utf-8?q?Bj=C3=B6rn_Roy_Baron?= " <[email protected]>
Cc: Benno Lossin <[email protected]>
Cc: Andreas Hindborg <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Borislav Petkov <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: "H. Peter Anvin" <[email protected]>
Cc: Sean Christopherson <[email protected]>
Cc: Uros Bizjak <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Will Deacon <[email protected]>
Cc: Marc Zyngier <[email protected]>
Cc: Oliver Upton <[email protected]>
Cc: Mark Rutland <[email protected]>
Cc: Ryan Roberts <[email protected]>
Cc: Fuad Tabba <[email protected]>
Cc: Paul Walmsley <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Cc: Albert Ou <[email protected]>
Cc: Anup Patel <[email protected]>
Cc: Andrew Jones <[email protected]>
Cc: Alexandre Ghiti <[email protected]>
Cc: Conor Dooley <[email protected]>
Cc: Samuel Holland <[email protected]>
Cc: Huacai Chen <[email protected]>
Cc: WANG Xuerui <[email protected]>
Cc: Bibo Mao <[email protected]>
Cc: Tiezhu Yang <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Tianrui Zhao <[email protected]>
Link: https://lore.kernel.org/[email protected]
Suggested-by: Peter Zijlstra (Intel) <[email protected]>
Co-developed-by: Miguel Ojeda <[email protected]>
Signed-off-by: Miguel Ojeda <[email protected]>
Reviewed-by: Boqun Feng <[email protected]>
Signed-off-by: Alice Ryhl <[email protected]>
Signed-off-by: Steven Rostedt (Google) <[email protected]>

show more ...

rust: enable macros::module! tests

Previously, these tests were ignored due to a missing necessary dependency
on the `kernel` crate. Enable the tests, and update them: for both,
add the parameter to

rust: enable macros::module! tests

Previously, these tests were ignored due to a missing necessary dependency
on the `kernel` crate. Enable the tests, and update them: for both,
add the parameter to `init()`; for the first one, remove the use of a
kernel parameter mechanism that was never merged.

Signed-off-by: Ethan D. Twardy <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Link: https://github.com/Rust-for-Linux/linux/issues/1076
Link: https://lore.kernel.org/r/[email protected]
[ Rebased (moved the `export` to the `rustdoc_test` rule, enable the
firmware example too). Removed `export` for `RUST_MODFILE`. Removed
unneeded `rust` language in examples, as well as `#[macro_use]`
`extern`s. Reworded accordingly. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: kbuild: expand rusttest target for macros

Previously, the rusttest target for the macros crate did not specify
the dependencies necessary to run the rustdoc tests. These tests rely on
the kern

rust: kbuild: expand rusttest target for macros

Previously, the rusttest target for the macros crate did not specify
the dependencies necessary to run the rustdoc tests. These tests rely on
the kernel crate, so add the dependencies.

Signed-off-by: Ethan D. Twardy <[email protected]>
Link: https://github.com/Rust-for-Linux/linux/issues/1076
Link: https://lore.kernel.org/r/[email protected]
[ Rebased (`alloc` is gone nowadays, sysroot handling is simpler) and
simplified (reused `rustdoc_test` rule instead of adding a new one,
no need for `rustdoc-compiler_builtins`, removed unneeded `macros`
explicit path). Made `vtable` example fail (avoiding to increase
the complexity in the `rusttest` target). Removed unstable
`-Zproc-macro-backtrace` option. Reworded accordingly. - Miguel ]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

kbuild: rust: remove the `alloc` crate and `GlobalAlloc`

Now that we have our own `Allocator`, `Box` and `Vec` types we can remove
Rust's `alloc` crate and the `new_uninit` unstable feature.

Also r

kbuild: rust: remove the `alloc` crate and `GlobalAlloc`

Now that we have our own `Allocator`, `Box` and `Vec` types we can remove
Rust's `alloc` crate and the `new_uninit` unstable feature.

Also remove `Kmalloc`'s `GlobalAlloc` implementation -- we can't remove
this in a separate patch, since the `alloc` crate requires a
`#[global_allocator]` to set, that implements `GlobalAlloc`.

Signed-off-by: Danilo Krummrich <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...

rust: enable `rustdoc::unescaped_backticks` lint

In Rust 1.71.0, `rustdoc` added the `unescaped_backticks` lint, which
detects what are typically typos in Markdown formatting regarding inline
code [

rust: enable `rustdoc::unescaped_backticks` lint

In Rust 1.71.0, `rustdoc` added the `unescaped_backticks` lint, which
detects what are typically typos in Markdown formatting regarding inline
code [1], e.g. from the Rust standard library:

/// ... to `deref`/`deref_mut`` must ...

/// ... use [`from_mut`]`. Specifically, ...

It does not seem to have almost any false positives, from the experience
of enabling it in the Rust standard library [2], which will be checked
starting with Rust 1.82.0. The maintainers also confirmed it is ready
to be used.

Thus enable it.

Link: https://doc.rust-lang.org/rustdoc/lints.html#unescaped_backticks [1]
Link: https://github.com/rust-lang/rust/pull/128307 [2]
Reviewed-by: Trevor Gross <[email protected]>
Reviewed-by: Alice Ryhl <[email protected]>
Tested-by: Gary Guo <[email protected]>
Reviewed-by: Gary Guo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Miguel Ojeda <[email protected]>

show more ...