summaryrefslogtreecommitdiff
path: root/rust/kernel
AgeCommit message (Collapse)Author
2026-03-23rust: str: improve safety comment for CString::try_from_fmtNakamura Shuta
Improve the safety comment for the `inc_len()` call in `CString::try_from_fmt()` to clarify why `bytes_written()` is guaranteed not to exceed the buffer capacity. The current comment states that bytes written is bounded by size, but does not explain that this invariant is maintained because: 1. The `Formatter` is created with `size` as its capacity limit 2. The `?` operators on `write_fmt` and `write_str` ensure early return if writing exceeds this limit Suggested-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/rust-for-linux/20221114145329.0f47a3ab@GaryWorkstation/ Link: https://github.com/Rust-for-Linux/linux/issues/936 Signed-off-by: Nakamura Shuta <nakamura.shuta@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260119062925.1647-1-nakamura.shuta@gmail.com [ Updated tags: it was a suggestion from Gary from the mailing list (the linked issue is mostly about adding a `debug_assert_eq!`). - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-18rust: devres: embed struct devres_node directlyDanilo Krummrich
Currently, the Devres<T> container uses devm_add_action() to register a devres callback. devm_add_action() allocates a struct action_devres, which on top of struct devres_node, just keeps a data pointer and release function pointer. This is an unnecessary indirection, given that analogous to struct devres, the Devres<T> container can just embed a struct devres_node directly without an additional allocation. In contrast to struct devres, we don't need to force an alignment of ARCH_DMA_MINALIGN (as struct devres does to account for the worst case) since we have generics in Rust. I.e. the compiler already ensures correct alignment of the embedded T in Devres<T>. Thus, get rid of devm_add_action() and instead embed a struct devres_node directly. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patch.msgid.link/20260213220718.82835-6-dakr@kernel.org [ * Improve comment about core::any::type_name(), * add #[must_use] to devres_node_remove(), * use container_of!() in devres_node_free_node(). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17Merge tag 'rust_io-7.1-rc1' of ↵Danilo Krummrich
git://git.kernel.org/pub/scm/linux/kernel/git/driver-core/driver-core into drm-rust-next Register abstraction and I/O infrastructure improvements Introduce the register!() macro to define type-safe I/O register accesses. Refactor the IoCapable trait into a functional trait, which simplifies I/O backends and removes the need for overloaded Io methods. This is a stable tag for other trees to merge. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17Merge tag 'rust_io-7.1-rc1' into driver-core-nextDanilo Krummrich
Register abstraction and I/O infrastructure improvements Introduce the register!() macro to define type-safe I/O register accesses. Refactor the IoCapable trait into a functional trait, which simplifies I/O backends and removes the need for overloaded Io methods. This is a stable tag for other trees to merge. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: introduce `write_reg` and `LocatedRegister`Alexandre Courbot
Some I/O types, like fixed address registers, carry their location alongside their values. For these types, the regular `Io::write` method can lead into repeating the location information twice: once to provide the location itself, another time to build the value. We are also considering supporting making all register values carry their full location information for convenience and safety. Add a new `Io::write_reg` method that takes a single argument implementing `LocatedRegister`, a trait that decomposes implementors into a `(location, value)` tuple. This allows write operations on fixed offset registers to be done while specifying their name only once. Suggested-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/all/DH0XBLXZD81K.22SWIZ1ZAOW1@kernel.org/ Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260314-register-v9-8-86805b2f7e9d@nvidia.com [ Replace FIFO with VERSION register in the examples. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: add `register!` macroAlexandre Courbot
Add a macro for defining hardware register types with I/O accessors. Each register field is represented as a `Bounded` of the appropriate bit width, ensuring field values are never silently truncated. Fields can optionally be converted to/from custom types, either fallibly or infallibly. The address of registers can be direct, relative, or indexed, supporting most of the patterns in which registers are arranged. Suggested-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/all/20250306222336.23482-6-dakr@kernel.org/ Co-developed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260314-register-v9-7-86805b2f7e9d@nvidia.com [ * Improve wording and formatting of doc-comments, * Import build_assert!(), * Add missing inline annotations, * Call static_assert!() with absolute path, * Use expect instead of allow. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: use generic read/write accessors for primitive accessesAlexandre Courbot
By providing the required `IoLoc` implementations on `usize`, we can leverage the generic accessors and reduce the number of unsafe blocks in the module. This also allows us to directly call the generic `read/write/update` methods with primitive types, so add examples illustrating this. Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260314-register-v9-6-86805b2f7e9d@nvidia.com [ Slightly improve wording in doc-comment. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: add IoLoc type and generic I/O accessorsAlexandre Courbot
I/O accesses are defined by the following properties: - An I/O location, which consists of a start address, a width, and a type to interpret the read value as, - A value, which is returned for reads or provided for writes. Introduce the `IoLoc` trait, which allows implementing types to fully specify an I/O location. This allows I/O operations to be made generic through the new `read` and `write` methods. This design will allow us to factorize the I/O code working with primitives, and to introduce ways to perform I/O with a higher degree of control through register types. Co-developed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260314-register-v9-5-86805b2f7e9d@nvidia.com [ Fix incorrect reference to io_addr_assert() in try_update(). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: num: make Bounded::get constAlexandre Courbot
There is a need to access the inner value of a `Bounded` in const context, notably for bitfields and registers. Remove the invariant check of `Bounded::get`, which allows us to make it const. Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260314-register-v9-4-86805b2f7e9d@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: num: add `into_bool` method to `Bounded`Alexandre Courbot
Single-bit numbers are typically treated as booleans. There is an `Into<bool>` implementation for those, but invoking it from contexts that lack type expectations is not always convenient. Add an `into_bool` method as a simpler shortcut. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Yury Norov <yury.norov@gmail.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260314-register-v9-3-86805b2f7e9d@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: num: add `shr` and `shl` methods to `Bounded`Alexandre Courbot
Shifting a `Bounded` left or right changes the number of bits required to represent the value. Add methods that perform the shift and return a `Bounded` with the appropriately adjusted bit width. These methods are particularly useful for bitfield extraction. Suggested-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Acked-by: Yury Norov <ynorov@nvidia.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260314-register-v9-2-86805b2f7e9d@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: enable the `generic_arg_infer` featureAlexandre Courbot
This feature is stable since 1.89, and used in subsequent patches. Reviewed-by: Gary Guo <gary@garyguo.net> Tested-by: Dirk Behme <dirk.behme@de.bosch.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Link: https://patch.msgid.link/20260314-register-v9-1-86805b2f7e9d@nvidia.com [ Resolve merge conflict. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: remove overloaded Io methods of MmioAlexandre Courbot
Since `Mmio` now has the relevant implementations of `IoCapable`, the default methods of `Io` can be used in place of the overloaded ones. Remove them as well as the macros generating them. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Acked-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260206-io-v2-6-71dea20a06e6@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: pci: io: remove overloaded Io methods of ConfigSpaceAlexandre Courbot
Since `ConfigSpace` now has the relevant implementations of `IoCapable`, the default methods of `Io` can be used in place of the overloaded ones. Remove them as well as the macros generating them. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Acked-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260206-io-v2-5-71dea20a06e6@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: remove legacy relaxed accessors of MmioAlexandre Courbot
The relaxed access functionality is now provided by the `RelaxedMmio` wrapper type, and we don't have any user of the legacy methods left. Remove them. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Acked-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260206-io-v2-4-71dea20a06e6@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: provide Mmio relaxed ops through a wrapper typeAlexandre Courbot
Relaxed I/O accessors for `Mmio` are currently implemented as an extra set of methods that mirror the ones defined in `Io`, but with the `_relaxed` suffix. This makes these methods impossible to use with generic code, which is a highly plausible proposition now that we have the `Io` trait. Address this by adding a new `RelaxedMmio` wrapper type for `Mmio` that provides its own `IoCapable` implementations relying on the relaxed C accessors. This makes it possible to use relaxed operations on a `Mmio` simply by wrapping it, and to use `RelaxedMmio` in code generic against `Io`. Acked-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260206-io-v2-3-71dea20a06e6@nvidia.com [ Use kernel import style in examples. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: mem: use non-relaxed I/O ops in examplesAlexandre Courbot
The `_relaxed` I/O variant methods are about to be replaced by a wrapper type exposing this access pattern with the regular methods of the `Io` trait. Thus replace the examples to use the regular I/O methods. Since these are examples, we want them to use the most standard ops anyway, and the relaxed variants were but an addition that was MMIO-specific. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Acked-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260206-io-v2-2-71dea20a06e6@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-17rust: io: turn IoCapable into a functional traitAlexandre Courbot
`IoCapable<T>` is currently used as a marker trait to signal that the methods of the `Io` trait corresponding to `T` have been overridden by the implementor (the default implementations triggering a build-time error). This goes against the DRY principle and separates the signaling of the capability from its implementation, making it possible to forget a step while implementing a new `Io`. Another undesirable side-effect is that it makes the implementation of I/O backends boilerplate-y and convoluted: currently this is done using two levels of imbricated macros that generate unsafe code. Fix these issues by turning `IoCapable` into a functional trait that includes the raw implementation of the I/O access for `T` using unsafe methods that work with an arbitrary address. This allows us to turn the default methods of `Io` into regular methods that check the passed offset, turn it into an address, and call into the corresponding `IoCapable` functions, removing the need to overload them at all. `IoCapable` must still be implemented for all supported primitive types, which is still done more concisely using a macro, but this macro becomes much simpler and does not require calling into another one. Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Acked-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260206-io-v2-1-71dea20a06e6@nvidia.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-16Merge 7.0-rc4 into char-misc-nextGreg Kroah-Hartman
We need the char/misc/iio fixes in this branch as well to build on top of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-03-15Merge tag 'v7.0-rc4' into drm-rust-nextDanilo Krummrich
We need the latest fixes from drm-rust-fixes in drm-rust-next as well to build on top of. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-15rust: types: remove temporary re-exports of ARef and AlwaysRefCountedShankari Anand
Remove the temporary re-exports of `ARef` and `AlwaysRefCounted` from `types.rs` now that all in-tree users have been updated to import them directly from `sync::aref`. These re-exports were originally added to avoid breaking the kernel build during the transition period while call sites were incrementally migrated. With all users updated, they are no longer needed. Suggested-by: Benno Lossin <lossin@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1173 Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com> Link: https://patch.msgid.link/20260102202714.184223-5-shankari.ak0208@gmail.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-15rust: usb: Update AlwaysRefCounted imports to use sync::arefShankari Anand
Update call sites in `usb.rs` to import `AlwaysRefCounted` from `sync::aref` instead of `types`. This aligns with the ongoing effort to move `ARef` and `AlwaysRefCounted` to sync. Suggested-by: Benno Lossin <lossin@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1173 Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com> Link: https://patch.msgid.link/20260102202714.184223-4-shankari.ak0208@gmail.com [ Rebase. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-15rust: i2c: Update ARef and AlwaysRefCounted imports to use sync::arefShankari Anand
Update call sites in `i2c.rs` to import `ARef` and `AlwaysRefCounted` from `sync::aref` instead of `types`. This aligns with the ongoing effort to move `ARef` and `AlwaysRefCounted` to sync. Suggested-by: Benno Lossin <lossin@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1173 Signed-off-by: Shankari Anand <shankari.ak0208@gmail.com> Acked-by: Igor Korotin <igor.korotin.linux@gmail.com> Link: https://patch.msgid.link/20260102202714.184223-3-shankari.ak0208@gmail.com [ Move `ARef` import into the `kernel` `use` tree above. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-15rust: str: update `c_str!` documentationTamir Duberstein
Now that all literals are C-Strings, update the documentation to explain that use of this macro should be limited to non-literal strings. Link: https://github.com/Rust-for-Linux/linux/issues/1075 Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260309-cstr-rename-macro-v2-1-25f7de75944e@kernel.org [ Apply sentence case to comment. Reword title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-14Merge tag 'rust-fixes-7.0-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux Pull Rust fixes from Miguel Ojeda: "Toolchain and infrastructure: - Remap paths to avoid absolute ones starting with the upcoming Rust 1.95.0 release. This improves build reproducibility, avoids leaking the exact path and avoids having the same path appear in two forms The approach here avoids remapping debug information as well, in order to avoid breaking tools that used the paths to access source files, which was the previous attempt that needed to be reverted - Allow 'unused_features' lint for the upcoming Rust 1.96.0 release. While well-intentioned, we do not benefit much from the new lint - Emit dependency information into '$(depfile)' directly to avoid a temporary '.d' file (it was an old approach) 'kernel' crate: - 'str' module: fix warning under '!CONFIG_BLOCK' by making 'NullTerminatedFormatter' public - 'cpufreq' module: suppress false positive Clippy warning 'pin-init' crate: - Remove '#[disable_initialized_field_access]' attribute which was unsound. This means removing the support for structs with unaligned fields (through the 'repr(packed)' attribute), for now And document the load-bearing fact of field accessors (i.e. that they are required for soundness) - Replace shadowed return token by 'unsafe'-to-create token in order to remain sound in the face of the likely upcoming Type Alias Impl Trait (TAIT) and the next trait solver in upstream Rust" * tag 'rust-fixes-7.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux: rust: kbuild: allow `unused_features` rust: cpufreq: suppress clippy::double_parens in Policy doctest rust: pin-init: replace shadowed return token by `unsafe`-to-create token rust: pin-init: internal: init: document load-bearing fact of field accessors rust: pin-init: internal: init: remove `#[disable_initialized_field_access]` rust: build: remap path to avoid absolute path rust: kbuild: emit dep-info into $(depfile) directly rust: str: make NullTerminatedFormatter public
2026-03-13Merge tag 'drm-rust-fixes-2026-03-12' of ↵Dave Airlie
https://gitlab.freedesktop.org/drm/rust/kernel into drm-fixes Core Changes: - Fix safety issue in dma_read! and dma_write!. Driver Changes (Nova Core): - Fix UB in DmaGspMem pointer accessors. - Fix stack overflow in GSP memory allocation. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/abNBSol3CLRCqlkZ@google.com
2026-03-12rust: cpufreq: suppress clippy::double_parens in Policy doctestJohn Hubbard
The kernel fmt! proc macro wraps each format argument as &(arg). Passing a tuple such as (a, b) produces &((a, b)) after expansion. Clippy flags that as double_parens, but it is a false positive fixed in Clippy 1.92 [1] [2]. Suppress the warning on the affected doctest function with a reason attribute so it can be removed once the minimum toolchain moves past 1.92. [ We may end up deciding to support per-version Clippy lints, in which case we will need [3]. In the future, if [4] gets fixed, we may be able to use `Delimiter::None` as Gary suggested in [5]. Link: https://lore.kernel.org/rust-for-linux/20260307170929.153892-1-ojeda@kernel.org/ [3] Link: https://github.com/rust-lang/rust/issues/67062 [4] Link: https://lore.kernel.org/rust-for-linux/DGUA5GY2DGYN.3PG0FKLG7GFN1@garyguo.net/ [5] - Miguel ] Link: https://github.com/rust-lang/rust-clippy/issues/15852 [1] Link: https://github.com/rust-lang/rust-clippy/pull/15939 [2] Suggested-by: Gary Guo <gary@garyguo.net> Signed-off-by: John Hubbard <jhubbard@nvidia.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://patch.msgid.link/20260312041934.362840-2-jhubbard@nvidia.com [ Reworded to replace GitHub-like short link with full URLs in Link tags. Reworded reason string to match the style of a couple others we have elsewhere. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-11rust: disallow use of `CStr::as_ptr` and `CStr::from_ptr`Gary Guo
As kernel always use unsigned char and not the platform ABI's default, an user should always use `as_char_ptr` provided via `CStrExt` instead. Therefore configure `disallow-methods` feature of clippy to catch incorrect usage. Similarly, the dual `from_ptr` is also disallowed. [ As an example, without the previous commit, we would get a warning like: warning: use of a disallowed method `core::ffi::CStr::as_ptr` --> rust/kernel/task.rs:422:54 | 422 | unsafe { crate::bindings::__might_sleep(file.as_ptr().cast(), loc.line() as i32) } | ^^^^^^ help: kernel's `char` is always unsigned, use `as_char_ptr` instead: `kernel::prelude::CStrExt::as_char_ptr` | = help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.94.0/index.html#disallowed_methods = note: `-W clippy::disallowed-methods` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::disallowed_methods)]` - Miguel ] Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260203130745.868762-2-gary@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-10rust: task: use `as_char_ptr` instead of `as_ptr().cast()`Gary Guo
`as_char_ptr` would provide the correct (unsigned char) type without needing to convert to an intermediate type and cast the pointer. The `as_ptr()` function is going to be disallowed by clippy warning, so fix this usage. This is used only if CONFIG_DEBUG_ATOMIC_SLEEP=y. Instead of conditionally importing `CStrExt`, import it via prelude instead, and remove other imports that are already available via the prelude. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202601221157.89t3Sqbl-lkp@intel.com/ Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260203130745.868762-1-gary@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-10rust: add EMSGSIZE error codeEliot Courtney
Add the EMSGSIZE error code, which indicates that a message is too long. Tested-by: Zhi Wang <zhiw@nvidia.com> Acked-by: Miguel Ojeda <ojeda@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Eliot Courtney <ecourtney@nvidia.com> Link: https://patch.msgid.link/20260306-cmdq-continuation-v6-3-cc7b629200ee@nvidia.com Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
2026-03-09Merge tag 'v7.0-rc3' into driver-core-nextDanilo Krummrich
We need the driver-core fixes in here as well to build on top of. Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-08rust: atomic: Update a safety comment in impl of `fetch_add()`Andreas Hindborg
The safety comment used in the implementation of `fetch_add()` could be read as just saying something it is true without justifying it. Update the safety comment to include justification. Suggested-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Boqun Feng <boqun@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260220-atomic-sub-v3-3-e63cbed1d2aa@kernel.org Link: https://patch.msgid.link/20260303201701.12204-14-boqun@kernel.org
2026-03-08rust: sync: atomic: Update documentation for `fetch_add()`Andreas Hindborg
The documentation for `fetch_add()` does not indicate that the original value is returned by `fetch_add()`. Update the documentation so this is clear. Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Boqun Feng <boqun@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260220-atomic-sub-v3-2-e63cbed1d2aa@kernel.org Link: https://patch.msgid.link/20260303201701.12204-13-boqun@kernel.org
2026-03-08rust: sync: atomic: Add fetch_sub()Andreas Hindborg
Add `Atomic::fetch_sub()` with implementation and documentation in line with existing `Atomic::fetch_add()` implementation. Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Boqun Feng <boqun@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260220-atomic-sub-v3-1-e63cbed1d2aa@kernel.org Link: https://patch.msgid.link/20260303201701.12204-12-boqun@kernel.org
2026-03-08rust: sync: atomic: Add atomic operation helpers over raw pointersBoqun Feng
In order to synchronize with C or external memory, atomic operations over raw pointers are need. Although there is already an `Atomic::from_ptr()` to provide a `&Atomic<T>`, it's more convenient to have helpers that directly perform atomic operations on raw pointers. Hence a few are added, which are basically an `Atomic::from_ptr().op()` wrapper. Note: for naming, since `atomic_xchg()` and `atomic_cmpxchg()` have a conflict naming to 32bit C atomic xchg/cmpxchg, hence the helpers are just named as `xchg()` and `cmpxchg()`. For `atomic_load()` and `atomic_store()`, their 32bit C counterparts are `atomic_read()` and `atomic_set()`, so keep the `atomic_` prefix. [boqun: Fix typo spotted by Alice and fix broken sentence spotted by Gary] Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260120115207.55318-3-boqun.feng@gmail.com Link: https://patch.msgid.link/20260303201701.12204-11-boqun@kernel.org
2026-03-08rust: list: Use AtomicFlag in AtomicTrackerFUJITA Tomonori
Make AtomicTracker use AtomicFlag instead of Atomic<bool> to avoid slow byte-sized RMWs on architectures that don't support them. Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: Boqun Feng <boqun@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260129122622.3896144-3-tomo@aliasing.net Link: https://patch.msgid.link/20260303201701.12204-10-boqun@kernel.org
2026-03-08rust: sync: atomic: Add performance-optimal Flag type for atomic booleansFUJITA Tomonori
Add AtomicFlag type for boolean flags. Document when AtomicFlag is generally preferable to Atomic<bool>: in particular, when RMW operations such as xchg()/cmpxchg() may be used and minimizing memory usage is not the top priority. On some architectures without byte-sized RMW instructions, Atomic<bool> can be slower for RMW operations. Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: Boqun Feng <boqun@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260129122622.3896144-2-tomo@aliasing.net Link: https://patch.msgid.link/20260303201701.12204-9-boqun@kernel.org
2026-03-08rust: sync: atomic: Add Atomic<*{mut,const} T> supportBoqun Feng
Atomic pointer support is an important piece of synchronization algorithm, e.g. RCU, hence provide the support for that. Note that instead of relying on atomic_long or the implementation of `Atomic<usize>`, a new set of helpers (atomic_ptr_*) is introduced for atomic pointer specifically, this is because ptr2int casting would lose the provenance of a pointer and even though in theory there are a few tricks the provenance can be restored, it'll still be a simpler implementation if C could provide atomic pointers directly. The side effects of this approach are: we don't have the arithmetic and logical operations for pointers yet and the current implementation only works on ARCH_SUPPORTS_ATOMIC_RMW architectures, but these are implementation issues and can be added later. Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Link: https://patch.msgid.link/20260120140503.62804-3-boqun.feng@gmail.com Link: https://patch.msgid.link/20260303201701.12204-8-boqun@kernel.org
2026-03-08rust: sync: atomic: Clarify the need of CONFIG_ARCH_SUPPORTS_ATOMIC_RMWBoqun Feng
Currently, since all the architectures that support Rust all have CONFIG_ARCH_SUPPORTS_ATOMIC_RMW selected, the helpers of atomic load/store on i8 and i16 relies on CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y. It's generally fine since most of architectures support that. The plan for CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=n architectures is adding their (probably lock-based) atomic load/store for i8 and i16 as their atomic_{read,set}() and atomic64_{read,set}() counterpart when they plans to support Rust. Hence use a statis_assert!() to check this and remind the future us the need of the helpers. This is more clear than the #[cfg] on impl blocks of i8 and i16. Suggested-by: Dirk Behme <dirk.behme@gmail.com> Suggested-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260120140503.62804-2-boqun.feng@gmail.com Link: https://patch.msgid.link/20260303201701.12204-7-boqun@kernel.org
2026-03-08rust: sync: atomic: Add example for Atomic::get_mut()FUJITA Tomonori
Add an example for Atomic::get_mut(). No functional change. Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Signed-off-by: Boqun Feng <boqun@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260128123313.3850604-1-tomo@aliasing.net Link: https://patch.msgid.link/20260303201701.12204-3-boqun@kernel.org
2026-03-08rust: sync: atomic: Remove bound `T: Sync` for `Atomic::from_ptr()`Boqun Feng
Originally, `Atomic::from_ptr()` requires `T` being a `Sync` because I thought having the ability to do `from_ptr()` meant multiplle `&Atomic<T>`s shared by different threads, which was identical (or similar) to multiple `&T`s shared by different threads. Hence `T` was required to be `Sync`. However this is not true, since `&Atomic<T>` is not the same at `&T`. Moreover, having this bound makes `Atomic::<*mut T>::from_ptr()` impossible, which is definitely not intended. Therefore remove the `T: Sync` bound. [boqun: Fix title typo spotted by Alice & Gary] Fixes: 29c32c405e53 ("rust: sync: atomic: Add generic atomics") Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260120115207.55318-2-boqun.feng@gmail.com Link: https://patch.msgid.link/20260303201701.12204-2-boqun@kernel.org
2026-03-07rust: dma: use pointer projection infra for `dma_{read,write}` macroGary Guo
Current `dma_read!`, `dma_write!` macros also use a custom `addr_of!()`-based implementation for projecting pointers, which has soundness issue as it relies on absence of `Deref` implementation on types. It also has a soundness issue where it does not protect against unaligned fields (when `#[repr(packed)]` is used) so it can generate misaligned accesses. This commit migrates them to use the general pointer projection infrastructure, which handles these cases correctly. As part of migration, the macro is updated to have an improved surface syntax. The current macro have dma_read!(a.b.c[d].e.f) to mean `a.b.c` is a DMA coherent allocation and it should project into it with `[d].e.f` and do a read, which is confusing as it makes the indexing operator integral to the macro (so it will break if you have an array of `CoherentAllocation`, for example). This also is problematic as we would like to generalize `CoherentAllocation` from just slices to arbitrary types. Make the macro expects `dma_read!(path.to.dma, .path.inside.dma)` as the canonical syntax. The index operator is no longer special and is just one type of projection (in additional to field projection). Similarly, make `dma_write!(path.to.dma, .path.inside.dma, value)` become the canonical syntax for writing. Another issue of the current macro is that it is always fallible. This makes sense with existing design of `CoherentAllocation`, but once we support fixed size arrays with `CoherentAllocation`, it is desirable to have the ability to perform infallible indexing as well, e.g. doing a `[0]` index of `[Foo; 2]` is okay and can be checked at build-time, so forcing falliblity is non-ideal. To capture this, the macro is changed to use `[idx]` as infallible projection and `[idx]?` as fallible index projection (those syntax are part of the general projection infra). A benefit of this is that while individual indexing operation may fail, the overall read/write operation is not fallible. Fixes: ad2907b4e308 ("rust: add dma coherent allocator abstraction") Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260302164239.284084-4-gary@kernel.org [ Capitalize safety comments; slightly improve wording in doc-comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-07rust: ptr: add projection infrastructureGary Guo
Add a generic infrastructure for performing field and index projections on raw pointers. This will form the basis of performing I/O projections. Pointers manipulations are intentionally using the safe wrapping variants instead of the unsafe variants, as the latter requires pointers to be inside an allocation which is not necessarily true for I/O pointers. This projection macro protects against rogue `Deref` implementation, which can causes the projected pointer to be outside the bounds of starting pointer. This is extremely unlikely and Rust has a lint to catch this, but is unsoundness regardless. The protection works by inducing type inference ambiguity when `Deref` is implemented. This projection macro also stops projecting into unaligned fields (i.e. fields of `#[repr(packed)]` structs), as misaligned pointers require special handling. This is implemented by attempting to create reference to projected field inside a `if false` block. Despite being unreachable, Rust still checks that they're not unaligned fields. The projection macro supports both fallible and infallible index projections. These are described in detail inside the documentation. Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Benno Lossin <lossin@kernel.org> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://patch.msgid.link/20260302164239.284084-3-gary@kernel.org [ * Add intro-doc links where possible, * Fix typos and slightly improve wording, e.g. "as documentation describes" -> "as the documentation of [`Self::proj`] describes", * Add an empty line between regular and safety comments, before examples, and between logically independent comments, * Capitalize various safety comments. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-07rust: ptr: add `KnownSize` trait to support DST size info extractionGary Guo
Add a `KnownSize` trait which is used obtain a size from a raw pointer's metadata. This makes it possible to obtain size information on a raw slice pointer. This is similar to Rust `core::mem::size_of_val_raw` which is not yet stable. Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Benno Lossin <lossin@kernel.org> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://patch.msgid.link/20260302164239.284084-2-gary@kernel.org [ Fix wording in doc-comment. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-06Merge tag 'linux_kselftest-kunit-fixes-7.0-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest Pull kunit fixes from Shuah Khan: - Fix rust warnings when CONFIG_PRINTK is disabled - Reduce stack usage in kunit_run_tests() to fix warnings when CONFIG_FRAME_WARN is set to a relatively low value - Update email address for David Gow - Copy caller args in kunit tool in run_kernel to prevent mutation * tag 'linux_kselftest-kunit-fixes-7.0-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest: kunit: reduce stack usage in kunit_run_tests() kunit: tool: copy caller args in run_kernel to prevent mutation rust: kunit: fix warning when !CONFIG_PRINTK MAINTAINERS: Update email address for David Gow
2026-03-04rust: str: make NullTerminatedFormatter publicAlexandre Courbot
If `CONFIG_BLOCK` is disabled, the following warnings are displayed during build: warning: struct `NullTerminatedFormatter` is never constructed --> ../rust/kernel/str.rs:667:19 | 667 | pub(crate) struct NullTerminatedFormatter<'a> { | ^^^^^^^^^^^^^^^^^^^^^^^ | = note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default warning: associated function `new` is never used --> ../rust/kernel/str.rs:673:19 | 671 | impl<'a> NullTerminatedFormatter<'a> { | ------------------------------------ associated function in this implementation 672 | /// Create a new [`Self`] instance. 673 | pub(crate) fn new(buffer: &'a mut [u8]) -> Option<NullTerminatedFormatter<'a>> { Fix them by making `NullTerminatedFormatter` public, as it could be useful for drivers anyway. Fixes: cdde7a1951ff ("rust: str: introduce `NullTerminatedFormatter`") Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Cc: stable@vger.kernel.org Link: https://patch.msgid.link/20260224-nullterminatedformatter-v1-1-5bef7b9b3d4c@nvidia.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-03-03rust: irq: move 'static bounds to traitsAlice Ryhl
The 'static bound is required by all irq handlers, so it is simpler to specify it on the trait declaration instead of repeating it every time the trait is used as a where clause. Note that we already list Sync on the trait bound for the same reason. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Benno Lossin <lossin@kernel.org> Link: https://patch.msgid.link/20260219-irq-static-on-trait-v1-1-6ede6b743ea3@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2026-03-02rust: kunit: fix warning when !CONFIG_PRINTKAlexandre Courbot
If `CONFIG_PRINTK` is not set, then the following warnings are issued during build: warning: unused variable: `args` --> ../rust/kernel/kunit.rs:16:12 | 16 | pub fn err(args: fmt::Arguments<'_>) { | ^^^^ help: if this is intentional, prefix it with an underscore: `_args` | = note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default warning: unused variable: `args` --> ../rust/kernel/kunit.rs:32:13 | 32 | pub fn info(args: fmt::Arguments<'_>) { | ^^^^ help: if this is intentional, prefix it with an underscore: `_args` Fix this by adding a no-op assignment using `args` when `CONFIG_PRINTK` is not set. Fixes: a66d733da801 ("rust: support running Rust documentation tests as KUnit ones") Signed-off-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: David Gow <david@davidgow.net> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2026-02-26rust: alloc: add KUnit tests for KVVec shrink_toShivam Kalra
Add comprehensive KUnit tests for the shrink_to method for KVVec. The tests verify: - Basic shrinking from multiple pages to fewer pages with data integrity preservation - Empty vector shrinking to zero capacity - No-op behavior when shrinking to a larger capacity than current - Respect for min_capacity parameter when larger than vector length These tests ensure that the shrinking logic correctly identifies when memory can be reclaimed (by freeing at least one page) and that data integrity is maintained throughout shrink operations. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in> Link: https://patch.msgid.link/20260216-binder-shrink-vec-v3-v6-2-ece8e8593e53@zohomail.in Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-26rust: kvec: implement shrink_to for KVVecShivam Kalra
Implement shrink_to method specifically for `KVVec` (i.e., `Vec<T, KVmalloc>`). `shrink_to` reduces the vector's capacity to a specified minimum. For kmalloc-backed allocations, the method delegates to realloc(), letting the allocator decide whether shrinking is worthwhile. For vmalloc-backed allocations (detected via is_vmalloc_addr), shrinking only occurs if at least one page of memory can be freed, using an explicit alloc+copy+free since vrealloc does not yet support in-place shrinking. A TODO note marks this for future replacement with a generic shrink_to for all allocators that uses A::realloc() once the underlying allocators properly support shrinking via realloc. Suggested-by: Alice Ryhl <aliceryhl@google.com> Suggested-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in> Link: https://patch.msgid.link/20260216-binder-shrink-vec-v3-v6-1-ece8e8593e53@zohomail.in Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-07 03:41:00 +0000