| Age | Commit message (Collapse) | Author |
|---|
|
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux
Pull Rust updates from Miguel Ojeda:
"Toolchain and infrastructure:
- Update vendored 'zerocopy' crate to v0.8.62 (released 2026-10-08).
This update advances 8 releases, with 3 of them carrying most of
the changes. It contains new features as well as fixes. However,
almost nothing has changed that requires updates on our side (a
move of our non-ASCII change and the addition of an SPDX license
identifier).
- Generate Rust KUnit test suites for doctests reusing the
'#[kunit_tests]' and '#[test]' attributes instead of C FFI
functions, which allows to remove the generated C glue file.
Relatedly, simplify 'kunit_assert!' by using 'file!()' and
'line!()' inside (which doctests override as needed), which allows
to remove the 'file' helper and 'CONFIG_RUSTC_HAS_SPAN_FILE'.
- Trim the function names in doctests generated by 'rustdoc' < 1.95.0
when building with 'O=', which were not reproducible.
- Fix the 'VM_MAYSHARE' value in the generated bindings and its
blocklist entry, due to typos.
- Build 'core' with '--cfg no_io_statics' to ensure 'core' does not
introduce any use of 'core::sync::atomic' into the kernel image
since upstream Rust is moving 'std::io::Error' into 'core', which
uses a global atomic pointer.
Upstream Rust merged a PR to add a test checking that builds of
'core' are warning-free with that 'cfg' enabled.
- Enable the unstable 'proc_macro_span' feature in 'proc-macro2',
which provides 'Span::join' and thus improves the quality of the
diagnostics of all our procedural macros, notably 'pin-init'. This
is only used for producing diagnostics, thus there is no hard
reliance on the feature.
- Globally allow 'clippy::comparison_chain', since its suggestions
are not always ideal and upstream downgraded it to 'pedantic' too.
'kernel' crate:
- New 'mem' module: add the 'Align<N>' zero-sized type so that
alignment can be specified via const generics ('repr(align(...))'
only works with integer literals), e.g.:
const N: usize = 128;
struct S {
_align: Align<N>,
}
assert_eq!(align_of::<S>(), N);
- New 'ratelimit' module: add the 'Ratelimit' abstraction for 'struct
ratelimit_state' and, based on it, the 'pr_*_ratelimited!' printing
macros, which can be used for printing that may be triggered by
userspace.
In addition, convert Rust Binder to use them.
- 'sync' module: to construct a global 'struct ratelimit_state', add
a 'const' constructor for 'raw_spinlock_t'.
In addition, move the lockdep types into a new 'sync::lockdep'
submodule, since there were starting to be too many of them.
- 'num' module: add the 'cv!' macro to create constant values ("cv")
from an integer constant expression, with validity checked at
compile time, inferring the target type from the context. It works
for any type that implements the new 'FromConst' trait, e.g.:
let a: Alignment = cv!(4096);
let b: Bounded<u32, 4> = cv!(15);
// Any integer constant expression works, not only literals.
let m: NonZero<usize> = cv!(usize::MAX);
// Checked narrowing, including in `const` items.
const SMALL: u8 = cv!(200u32);
// The target type can be given explicitly.
let e = cv!(200u32 => u8);
// With an explicit primitive target, the expression can use
// generic parameters.
const fn as_u64<const KEY: u16>() -> u64 {
cv!(KEY => u64)
}
This avoids the verbose turbofish syntax which disincentivized
using these types at interface boundaries (e.g.
'Alignment::new::<8>()').
- 'alloc' module:
- Allow different error types in 'KBox::pin_slice()', enabling use
of infallible initializers.
- Add 'NumaNode::id()' accessor to retrieve the underlying NUMA
node identifier.
- 'time' module:
- Add 'Delta::to_jiffies_timeout()' for use in timeout arguments.
- Add 'Delta::as_jiffies_unsigned()'.
- Make 'Delta::ZERO' generic over the time unit.
- Warn and assert when passing out-of-range inputs to 'fsleep' and
'udelay'.
- Rename 'ClockSource' to 'ClockId' to better align with naming
conventions in C kernel.
- Make 'CONFIG_HZ' value available as 'bindings::HZ'.
- Add implementation detail documentation for 'HrTimer'.
- 'bitmap' module:
- Add contiguous area operations ('next_zero_area{,_off}', 'set'
and 'clear'), with extra checks compared to the underlying C
code, plus additional ones under 'CONFIG_RUST_BITMAP_HARDENED'.
It includes tests demonstrating the edge cases.
- Restrict bitmap length to at most 'i32::MAX', matching
'BitmapVec::MAX_LEN' and simplifying a few things. This also
fixes 'u32' casts truncating in 'copy_and_extend', which could
otherwise lead to OOB writes.
- 'bug' module:
- Fix 'warn_on!' on UML which called 'warn_slowpath_fmt()' with
the wrong arguments; and fix its '// SAFETY:' comment too.
- Add a KUnit test for 'warn_on!'.
- 'id_pool' module: add contiguous ID reservation via the new
'reserve_ids' and 'release_ids' methods, built on top of the new
bitmap area operations.
- 'sizes' module: add the sub-1K size constants ('SZ_1' to 'SZ_512')
and implement 'SizeConstants' for 'Alignment', so that one can
write e.g. 'Alignment::SZ_8'.
'macros' crate:
- Add '#[optional]' attribute for optional methods in '#[vtable]' to
replace the 'build_error!(VTABLE_DEFAULT_ERROR)' boilerplate, e.g.:
#[vtable]
pub trait Operations: Sized {
#[optional]
fn f(&self) -> Result;
}
In addition, apply it to miscdevice and hide generated 'HAS_'
constants for required methods.
- Allow non-ASCII characters in the 'authors' field of the 'module!'
macro, which was unintentionally restricted when multiple authors
support was introduced.
'pin-init' crate:
[ Extra context from Gary's pull request:
"This is a cycle packed with feature updates. Two of the most
anticipated features, tuple struct support and safe self
reference creation, has been included in this pull request.
Safe self reference is a big one and is pushed a bit late in the
cycle. The initial plan was to include a minimum subset for this
cycle because I was worried about potential soundness issues;
however during Plumbers it was agreed that the features should be
upstreamed at once. This is because the initial users (Nova,
JobQueue) would all need the advanced features, so it is better
to ensure that the feature get put into use for real, and it can
iterate with users, rather than being fully designed on paper.
The existing safety checks are already very comprehensive, and
Benno and I are confident that if new ones are discovered, it
wouldn't affect the overall design.
That said, the the usage of the advanced features (invariance,
existential lifetime) shall be limited to the pre-agreed users
only, so even in case where the feature needs to be reworked, the
blast radius is limited.
Another theme in this cycle is to improve the developer
experience when things are used wrongly. A lot of work has been
done to use proper spans from user-provided tokens so error
message point to things that cause them. Many common misuse
scenarios also gain additional custom diagnostics." ]
- User visible changes:
- Support tuple structs.
- Allow safe creation of self references.
- Vastly improve diagnostics for common misuse scenarios.
- Other changes:
- Use 'mixed_site' hygiene consistently.
'MAINTAINERS':
- Add 'RUST [BUG]' entry for the Rust 'bug' module (i.e. 'warn_on!'),
which will be maintained by FUJITA Tomonori -- thank you!
- Add Alice Ryhl as co-maintainer for 'Rust [ALLOC]'.
And some other fixes, cleanups and improvements.
* tag 'rust-7.4' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: (91 commits)
rust: zerocopy: update to v0.8.62
rust: zerocopy: fix link to upstream `README.md`
rust: id_pool: add contiguous ID reservation
rust: bitmap: add contiguous area operations
rust: sizes: implement SizeConstants for Alignment
rust: sizes: add sub-1K size constants
rust: bitmap: restrict bitmap length to at most i32::MAX
rust: bitmap: use function-level cfg on kunit test
rust: num: add cv! macro to create values from constant expressions
rust: bug: update the SAFETY comment for warn_slowpath_fmt() on UML
rust: time: add Delta::as_jiffies_unsigned()
rust: time: make Delta::ZERO generic over the time unit
rust_binder: use pr_*_ratelimited! for printing
rust: add pr_*_ratelimited! macros for printing
rust: sync: add const constructor for raw_spinlock_t
rust: sync: move lockdep types to rust/kernel/sync/lockdep.rs
rust: pin-init: internal: suppress `explicit_outlives_requirements`
MAINTAINERS: add entry for the Rust `bug` module
rust: pin-init: internal: pin_data: support existential lifetimes
rust: pin-init: internal: pin_data: support shared projection
...
|
|
Add bindings for area operations on bitmaps. Each one is
made safe by adding some extra checks compared to the underlying C code
(for example, checking bounds) and with additional checks to catch
likely erroneous usage if `CONFIG_RUST_BITMAP_HARDENED` is on.
Add tests demonstrating the edge cases.
Reviewed-by: Burak Emir <burak.emir@gmail.com>
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Reviewed-by: Yury Norov <yury.norov@gmail.com>
Link: https://patch.msgid.link/20260930-chid-v9-6-0d6cca376cff@nvidia.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
It is currently possible to construct a non-`BitmapVec` backed `Bitmap`
using `Bitmap::from_raw` that is larger than `i32::MAX`, and it is not
part of the unsafe requirements. Restricting all bitmaps (even
non-`BitmapVec` backed ones) to a maximum size of `i32::MAX` simplifies
a few things and matches `BitmapVec::MAX_LEN`. For example,
`copy_and_extend` truncates `len` to u32, which is wrong for > u32::MAX
size. `__bitmap_set` and `__bitmap_clear` need i32 for `size` and u32
for `start` - so they can't be run on a `Bitmap` with a > i32::MAX size.
Rather than adding runtime checks to account for the case of a non
`BitmapVec` backed `Bitmap`, just include that in the requirements for
`Bitmap`.
Add that requirement to the unsafe requirements on `Bitmap::from_raw`
and `Bitmap::from_raw_mut`, and to the invariants on `Bitmap`.
This also fixes u32 casts truncating in `copy_and_extend`, which could
otherwise lead to OOB writes.
Fixes: 11eca92a2cae ("rust: add bitmap API.")
Link: https://lore.kernel.org/DKG0U8RLO7LZ.2I1AIH0S38PAP@nvidia.com
Reviewed-by: Yury Norov <ynorov@nvidia.com>
Reviewed-by: Burak Emir <burak.emir@gmail.com>
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260930-chid-v9-2-0d6cca376cff@nvidia.com
Cc: stable@vger.kernel.org
[ Added a few intra-doc links. Added backticks to C types. Capitalize
tagged comments. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Since commit c652dc44192d ("rust: kunit: allow `cfg` on `test`s"),
we no longer need this workaround.
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Yury Norov <ynorov@nvidia.com>
Reviewed-by: Burak Emir <burak.emir@gmail.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Eliot Courtney <ecourtney@nvidia.com>
Link: https://patch.msgid.link/20260930-chid-v9-1-0d6cca376cff@nvidia.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
`next_bit()` and `next_zero_bit()` use `bitmap_assert!()` to check
that `start` is less than `self.len()`, which panics when
`CONFIG_RUST_BITMAP_HARDENED` is enabled. However, neither function
has a `# Panics` section, and both document that `None` is returned
for exactly the input that triggers the panic.
Update the documentation of `next_bit()` and `next_zero_bit()` to add
the missing `# Panics` sections, add the missing blank doc comment line
before `Returns` in `next_zero_bit()`, and simplify the wording.
Fixes: 11eca92a2cae ("rust: add bitmap API.")
Closes: https://github.com/Rust-for-Linux/linux/issues/1252
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Georgios Androutsopoulos <georgeandrout13@gmail.com>
Signed-off-by: Yury Norov <ynorov@nvidia.com>
|
|
There are 6 individual Rust KUnit test suites (plus the doctests one). All
the tests are compiled unconditionally now, which adds ~200 kB to the
kernel image for me on x86_64. As Rust matures, this bloating will
inevitably grow.
Add Kconfig.test which includes a RUST_KUNIT_TESTS menu, and all
individual tests under it.
As usual, new tests are all enabled if KUNIT_ALL_TESTS=y.
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Yury Norov <ynorov@nvidia.com>
Reviewed-by: David Gow <david@davidgow.net>
Acked-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260417031531.315281-3-ynorov@nvidia.com
[ Fixed capitalization. Used singular for "API" for consistency.
Reworded to clarify these are suites and that there exists
the doctests one (which is the biggest at the moment by
far). - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
The following patch makes usage of macros::kunit_tests crate conditional
on the corresponding configs. When the configs are disabled, compiler
warns on unused crate. So, embed it in unit test declaration.
Signed-off-by: Yury Norov <ynorov@nvidia.com>
Reviewed-by: David Gow <david@davidgow.net>
Acked-by: Gary Guo <gary@garyguo.net>
Link: https://patch.msgid.link/20260417031531.315281-2-ynorov@nvidia.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
This constructor is useful when you just want to create a BitmapVec
without allocating but don't care how large it is.
Acked-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
Reviewed-by: Burak Emir <bqe@google.com>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
|
|
To avoid hard-coding these values in drivers, define constants for them
that drivers can reference. Also, update all instances in bitmap.rs and
id_pool.rs that use these values to use the new constants.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Burak Emir <bqe@google.com>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
|
|
We do our best to keep the repository `rustfmt`-clean, thus run the tool
to fix the formatting issue.
Link: https://docs.kernel.org/rust/coding-guidelines.html#style-formatting
Link: https://rust-for-linux.com/contributing#submit-checklist-addendum
Fixes: 0f5878834d6c ("rust: bitmap: clean Rust 1.92.0 `unused_unsafe` warning")
Reviewed-by: Burak Emir <bqe@google.com>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
|
|
Starting with Rust 1.92.0 (expected 2025-12-11), Rust allows to safely
take the address of a union field [1][2]:
CLIPPY L rust/kernel.o
error: unnecessary `unsafe` block
--> rust/kernel/bitmap.rs:169:13
|
169 | unsafe { core::ptr::addr_of!(self.repr.bitmap) }
| ^^^^^^ unnecessary `unsafe` block
|
= note: `-D unused-unsafe` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(unused_unsafe)]`
error: unnecessary `unsafe` block
--> rust/kernel/bitmap.rs:185:13
|
185 | unsafe { core::ptr::addr_of_mut!(self.repr.bitmap) }
| ^^^^^^ unnecessary `unsafe` block
Thus allow both instances to clean the warning in newer compilers.
Link: https://github.com/rust-lang/rust/issues/141264 [1]
Link: https://github.com/rust-lang/rust/pull/141469 [2]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
|
|
Microbenchmark protected by a config FIND_BIT_BENCHMARK_RUST,
following `find_bit_benchmark.c` but testing the Rust Bitmap API.
We add a fill_random() method protected by the config in order to
maintain the abstraction.
The sample output from the benchmark, both C and Rust version:
find_bit_benchmark.c output:
```
Start testing find_bit() with random-filled bitmap
[ 438.101937] find_next_bit: 860188 ns, 163419 iterations
[ 438.109471] find_next_zero_bit: 912342 ns, 164262 iterations
[ 438.116820] find_last_bit: 726003 ns, 163419 iterations
[ 438.130509] find_nth_bit: 7056993 ns, 16269 iterations
[ 438.139099] find_first_bit: 1963272 ns, 16270 iterations
[ 438.173043] find_first_and_bit: 27314224 ns, 32654 iterations
[ 438.180065] find_next_and_bit: 398752 ns, 73705 iterations
[ 438.186689]
Start testing find_bit() with sparse bitmap
[ 438.193375] find_next_bit: 9675 ns, 656 iterations
[ 438.201765] find_next_zero_bit: 1766136 ns, 327025 iterations
[ 438.208429] find_last_bit: 9017 ns, 656 iterations
[ 438.217816] find_nth_bit: 2749742 ns, 655 iterations
[ 438.225168] find_first_bit: 721799 ns, 656 iterations
[ 438.231797] find_first_and_bit: 2819 ns, 1 iterations
[ 438.238441] find_next_and_bit: 3159 ns, 1 iterations
```
find_bit_benchmark_rust.rs output:
```
[ 451.182459] find_bit_benchmark_rust:
[ 451.186688] Start testing find_bit() Rust with random-filled bitmap
[ 451.194450] next_bit: 777950 ns, 163644 iterations
[ 451.201997] next_zero_bit: 918889 ns, 164036 iterations
[ 451.208642] Start testing find_bit() Rust with sparse bitmap
[ 451.214300] next_bit: 9181 ns, 654 iterations
[ 451.222806] next_zero_bit: 1855504 ns, 327026 iterations
```
Here are the results from 32 samples, with 95% confidence interval.
The microbenchmark was built with RUST_BITMAP_HARDENED=n and run on a
machine that did not execute other processes.
Random-filled bitmap:
+-----------+-------+-----------+--------------+-----------+-----------+
| Benchmark | Lang | Mean (ms) | Std Dev (ms) | 95% CI Lo | 95% CI Hi |
+-----------+-------+-----------+--------------+-----------+-----------+
| find_bit/ | C | 825.07 | 53.89 | 806.40 | 843.74 |
| next_bit | Rust | 870.91 | 46.29 | 854.88 | 886.95 |
+-----------+-------+-----------+--------------+-----------+-----------+
| find_zero/| C | 933.56 | 56.34 | 914.04 | 953.08 |
| next_zero | Rust | 945.85 | 60.44 | 924.91 | 966.79 |
+-----------+-------+-----------+--------------+-----------+-----------+
Rust appears 5.5% slower for next_bit, 1.3% slower for next_zero.
Sparse bitmap:
+-----------+-------+-----------+--------------+-----------+-----------+
| Benchmark | Lang | Mean (ms) | Std Dev (ms) | 95% CI Lo | 95% CI Hi |
+-----------+-------+-----------+--------------+-----------+-----------+
| find_bit/ | C | 13.17 | 6.21 | 11.01 | 15.32 |
| next_bit | Rust | 14.30 | 8.27 | 11.43 | 17.17 |
+-----------+-------+-----------+--------------+-----------+-----------+
| find_zero/| C | 1859.31 | 82.30 | 1830.80 | 1887.83 |
| next_zero | Rust | 1908.09 | 139.82 | 1859.65 | 1956.54 |
+-----------+-------+-----------+--------------+-----------+-----------+
Rust appears 8.5% slower for next_bit, 2.6% slower for next_zero.
In summary, taking the arithmetic mean of all slow-downs, we can say
the Rust API has a 4.5% slowdown.
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Suggested-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
Reviewed-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Burak Emir <bqe@google.com>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
|
|
Provides an abstraction for C bitmap API and bitops operations.
This commit enables a Rust implementation of an Android Binder
data structure from commit 15d9da3f818c ("binder: use bitmap for faster
descriptor lookup"), which can be found in drivers/android/dbitmap.h.
It is a step towards upstreaming the Rust port of Android Binder driver.
We follow the C Bitmap API closely in naming and semantics, with
a few differences that take advantage of Rust language facilities
and idioms. The main types are `BitmapVec` for owned bitmaps and
`Bitmap` for references to C bitmaps.
* We leverage Rust type system guarantees as follows:
* all (non-atomic) mutating operations require a &mut reference which
amounts to exclusive access.
* the `BitmapVec` type implements Send. This enables transferring
ownership between threads and is needed for Binder.
* the `BitmapVec` type implements Sync, which enables passing shared
references &Bitmap between threads. Atomic operations can be
used to safely modify from multiple threads (interior
mutability), though without ordering guarantees.
* The Rust API uses `{set,clear}_bit` vs `{set,clear}_bit_atomic` as
names for clarity, which differs from the C naming convention
`set_bit` for atomic vs `__set_bit` for non-atomic.
* we include enough operations for the API to be useful. Not all
operations are exposed yet in order to avoid dead code. The missing
ones can be added later.
* We take a fine-grained approach to safety:
* Low-level bit-ops get a safe API with bounds checks. Calling with
an out-of-bounds arguments to {set,clear}_bit becomes a no-op and
get logged as errors.
* We also introduce a RUST_BITMAP_HARDENED config, which
causes invocations with out-of-bounds arguments to panic.
* methods correspond to find_* C methods tolerate out-of-bounds
since the C implementation does. Also here, out-of-bounds
arguments are logged as errors, or panic in RUST_BITMAP_HARDENED
mode.
* We add a way to "borrow" bitmaps from C in Rust, to make C bitmaps
that were allocated in C directly usable in Rust code (`Bitmap`).
* the Rust API is optimized to represent the bitmap inline if it would
fit into a pointer. This saves allocations which is
relevant in the Binder use case.
The underlying C bitmap is *not* exposed for raw access in Rust. Doing so
would permit bypassing the Rust API and lose static guarantees.
An alternative route of vendoring an existing Rust bitmap package was
considered but suboptimal overall. Reusing the C implementation is
preferable for a basic data structure like bitmaps. It enables Rust
code to be a lot more similar and predictable with respect to C code
that uses the same data structures and enables the use of code that
has been tried-and-tested in the kernel, with the same performance
characteristics whenever possible.
We use the `usize` type for sizes and indices into the bitmap,
because Rust generally always uses that type for indices and lengths
and it will be more convenient if the API accepts that type. This means
that we need to perform some casts to/from u32 and usize, since the C
headers use unsigned int instead of size_t/unsigned long for these
numbers in some places.
Adds new MAINTAINERS section BITMAP API [RUST].
Suggested-by: Alice Ryhl <aliceryhl@google.com>
Suggested-by: Yury Norov <yury.norov@gmail.com>
Signed-off-by: Burak Emir <bqe@google.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
|
