summaryrefslogtreecommitdiff
path: root/rust
AgeCommit message (Collapse)Author
2025-03-11rust: sync: add `Arc::as_ptr`Andreas Hindborg
Add a method to get a pointer to the data contained in an `Arc`. Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250309-hrtimer-v3-v6-12-rc2-v12-2-73586e2bd5f1@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2025-03-11rust: hrtimer: introduce hrtimer supportAndreas Hindborg
Add support for intrusive use of the hrtimer system. For now, only add support for embedding one timer per Rust struct. The hrtimer Rust API is based on the intrusive style pattern introduced by the Rust workqueue API. Acked-by: Frederic Weisbecker <frederic@kernel.org> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://lore.kernel.org/r/20250309-hrtimer-v3-v6-12-rc2-v12-1-73586e2bd5f1@kernel.org Signed-off-by: Andreas Hindborg <a.hindborg@kernel.org>
2025-03-11rust/kernel/faux: mark Registration methods inlineEthan Carter Edwards
When building the kernel on Arch Linux using on x86_64 with tools: $ rustc --version rustc 1.84.0 (9fc6b4312 2025-01-07) $ clang --version clang version 19.1.7 Target: x86_64-pc-linux-gnu The following symbols are generated: $ nm vmlinux | rg ' _R' | rustfilt | rg faux ffffffff81959ae0 T <kernel::faux::Registration>::new ffffffff81959b40 T <kernel::faux::Registration as core::ops::drop::Drop>::drop However, these Rust symbols are wrappers around bindings in the C faux code. Inlining these functions removes the middle-man wrapper function After applying this patch, the above function signatures disappear. Link: https://github.com/Rust-for-Linux/linux/issues/1145 Signed-off-by: Ethan Carter Edwards <ethan@ethancedwards.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/jesg4yu7m6fvzmgg5tlsktrrjm36l4qsranto5mdmnucx4pvf3@nhvt4juw5es3 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-10rust: task: fix `SAFETY` comment in `Task::wake_up`Panagiotis Foliadis
The `SAFETY` comment inside the `wake_up` method references erroneously the `signal_pending` C function instead of the `wake_up_process` which is actually called. Fix the comment to reference the correct C function. Fixes: fe95f58320e6 ("rust: task: adjust safety comments in Task methods") Signed-off-by: Panagiotis Foliadis <pfoliadis@posteo.net> Reviewed-by: Charalampos Mitrodimas <charmitro@posteo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250308-comment-fix-v1-1-4bba709fd36d@posteo.net [ Slightly reworded. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-10rust: types: add intra-doc links for `Opaque<T>`Dirk Behme
We use intra-doc links wherever possible. Thus add a couple missing ones for `Opaque<T>`. Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Fiona Behrens <me@kloenk.dev> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250305053438.1532397-1-dirk.behme@de.bosch.com [ Reworded. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-10rust: module: introduce `authors` keyGuilherme Giacomo Simoes
In the `module!` macro, the `author` field is currently of type `String`. Since modules can have multiple authors, this limitation prevents specifying more than one. Add an `authors` field as `Option<Vec<String>>` to allow creating modules with multiple authors, and change the documentation and all current users to use it. Eventually, the single `author` field may be removed. [ The `modinfo` key needs to still be `author`; otherwise, tooling may not work properly, e.g.: $ modinfo --author samples/rust/rust_print.ko Rust for Linux Contributors I have also kept the original `author` field (undocumented), so that we can drop it more easily in a kernel cycle or two. - Miguel ] Suggested-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/244 Reviewed-by: Charalampos Mitrodimas <charmitro@posteo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Guilherme Giacomo Simoes <trintaeoitogc@gmail.com> Link: https://lore.kernel.org/r/20250309175712.845622-2-trintaeoitogc@gmail.com [ Fixed `modinfo` key. Kept `author` field. Reworded message accordingly. Updated my email. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-10Merge 6.14-rc6 into char-misc-nextGreg Kroah-Hartman
We need the fixes in here as well to build on top of. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-09panic_qr: use new #[export] macroAlice Ryhl
This validates at compile time that the signatures match what is in the header file. It highlights one annoyance with the compile-time check, which is that it can only be used with functions marked unsafe. If the function is not unsafe, then this error is emitted: error[E0308]: `if` and `else` have incompatible types --> <linux>/drivers/gpu/drm/drm_panic_qr.rs:987:19 | 986 | #[export] | --------- expected because of this 987 | pub extern "C" fn drm_panic_qr_max_data_size(version: u8, url_len: usize) -> usize { | ^^^^^^^^^^^^^^^^^^^^^^^^^^ expected unsafe fn, found safe fn | = note: expected fn item `unsafe extern "C" fn(_, _) -> _ {kernel::bindings::drm_panic_qr_max_data_size}` found fn item `extern "C" fn(_, _) -> _ {drm_panic_qr_max_data_size}` The signature declarations are moved to a header file so it can be included in the Rust bindings helper, and the extern keyword is removed as it is unnecessary. Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Tamir Duberstein <tamird@gmail.com> Acked-by: Simona Vetter <simona.vetter@ffwll.ch> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20250303-export-macro-v3-5-41fbad85a27f@google.com [ Fixed `rustfmt`. Moved on top the unsafe requirement comment to follow the usual style, and slightly reworded it for clarity. Formatted bindings helper comment. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-09print: use new #[export] macro for rust_fmt_argumentAlice Ryhl
This moves the rust_fmt_argument function over to use the new #[export] macro, which will verify at compile-time that the function signature matches what is in the header file. Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Tamir Duberstein <tamird@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20250303-export-macro-v3-4-41fbad85a27f@google.com [ Removed period as requested by Andy. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-09rust: add #[export] macroAlice Ryhl
Rust has two different tools for generating function declarations to call across the FFI boundary: * bindgen. Generates Rust declarations from a C header. * cbindgen. Generates C headers from Rust declarations. However, we only use bindgen in the kernel. This means that when C code calls a Rust function by name, its signature must be duplicated in both Rust code and a C header, and the signature needs to be kept in sync manually. Introducing cbindgen as a mandatory dependency to build the kernel would be a rather complex and large change, so we do not consider that at this time. Instead, to eliminate this manual checking, introduce a new macro that verifies at compile time that the two function declarations use the same signature. The idea is to run the C declaration through bindgen, and then have rustc verify that the function pointers have the same type. The signature must still be written twice, but at least you can no longer get it wrong. If the signatures don't match, you will get errors that look like this: error[E0308]: `if` and `else` have incompatible types --> <linux>/rust/kernel/print.rs:22:22 | 21 | #[export] | --------- expected because of this 22 | unsafe extern "C" fn rust_fmt_argument( | ^^^^^^^^^^^^^^^^^ expected `u8`, found `i8` | = note: expected fn item `unsafe extern "C" fn(*mut u8, *mut u8, *mut c_void) -> *mut u8 {bindings::rust_fmt_argument}` found fn item `unsafe extern "C" fn(*mut i8, *mut i8, *const c_void) -> *mut i8 {print::rust_fmt_argument}` It is unfortunate that the error message starts out by saying "`if` and `else` have incompatible types", but I believe the rest of the error message is reasonably clear and not too confusing. Reviewed-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250303-export-macro-v3-3-41fbad85a27f@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-09rust: macros: support additional tokens in quote!Alice Ryhl
This gives the quote! macro support for the following additional tokens: * The = token. * The _ token. * The # token. (when not followed by an identifier) * Using #my_var with variables of type Ident. Additionally, some type annotations are added to allow cases where groups are empty. For example, quote! does support () in the input, but only when it is *not* empty. When it is empty, there are zero `.push` calls, so the compiler can't infer the item type and also emits a warning about it not needing to be mutable. These additional quote! features are used by a new proc macro that generates code looking like this: const _: () = { if true { ::kernel::bindings::#name } else { #name }; }; where #name has type Ident. Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Tamir Duberstein <tamird@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250303-export-macro-v3-2-41fbad85a27f@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-09rust: fix signature of rust_fmt_argumentAlice Ryhl
Without this change, the rest of this series will emit the following error message: error[E0308]: `if` and `else` have incompatible types --> <linux>/rust/kernel/print.rs:22:22 | 21 | #[export] | --------- expected because of this 22 | unsafe extern "C" fn rust_fmt_argument( | ^^^^^^^^^^^^^^^^^ expected `u8`, found `i8` | = note: expected fn item `unsafe extern "C" fn(*mut u8, *mut u8, *mut c_void) -> *mut u8 {bindings::rust_fmt_argument}` found fn item `unsafe extern "C" fn(*mut i8, *mut i8, *const c_void) -> *mut i8 {print::rust_fmt_argument}` The error may be different depending on the architecture. To fix this, change the void pointer argument to use a const pointer, and change the imports to use crate::ffi instead of core::ffi for integer types. Fixes: 787983da7718 ("vsprintf: add new `%pA` format specifier") Reviewed-by: Tamir Duberstein <tamird@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Petr Mladek <pmladek@suse.com> Link: https://lore.kernel.org/r/20250303-export-macro-v3-1-41fbad85a27f@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-09rust: firmware: add `module_firmware!` macroDanilo Krummrich
Analogous to the `module!` macro `module_firmware!` adds additional firmware path strings to the .modinfo section. In contrast to `module!`, where path strings need to be string literals, path strings can be composed with the `firmware::ModInfoBuilder`. Some drivers require a lot of firmware files (such as nova-core) and hence benefit from more flexibility composing firmware path strings. Acked-by: Jarkko Sakkinen <jarkko@kernel.org> Link: https://lore.kernel.org/r/20250306222336.23482-4-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-03-09rust: firmware: introduce `firmware::ModInfoBuilder`Danilo Krummrich
The `firmware` field of the `module!` only accepts literal strings, which is due to the fact that it is implemented as a proc macro. Some drivers require a lot of firmware files (such as nova-core) and hence benefit from more flexibility composing firmware path strings. The `firmware::ModInfoBuilder` is a helper component to flexibly compose firmware path strings for the .modinfo section in const context. It is meant to be used in combination with `kernel::module_firmware!`. Co-developed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250306222336.23482-3-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-03-09rust: module: add type `LocalModule`Danilo Krummrich
The `LocalModule` type is the type of the module created by `module!`, `module_pci_driver!`, `module_platform_driver!`, etc. Since the exact type of the module is sometimes generated on the fly by the listed macros, provide an alias. This is first used by the `module_firmware!` macro. Acked-by: Miguel Ojeda <ojeda@kernel.org> Suggested-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250306222336.23482-2-dakr@kernel.org Signed-off-by: Danilo Krummrich <dakr@kernel.org>
2025-03-08rust: improve lifetimes markupBorys Tyran
Improve lifetimes markup; e.g. from: /// ... 'a ... to: /// ... `'a` ... This will make lifetimes display as code span with Markdown and make it more consistent with rest of the docs. Link: https://github.com/Rust-for-Linux/linux/issues/1138 Signed-off-by: Borys Tyran <borys.tyran@protonmail.com> Link: https://lore.kernel.org/r/20250207142437.112435-1-borys.tyran@protonmail.com [ Reworded and changed Closes tag to Link. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-08rust: list: make the cursor point between elementsAlice Ryhl
I've been using the linked list cursor for a few different things, and I find it inconvenient to use because all of the functions have signatures along the lines of `Self -> Option<Self>`. The root cause of these signatures is that the cursor points *at* an element, rather than *between* two elements. Thus, change the cursor API to point between two elements. This is inspired by the stdlib linked list (well, really by this guy [1]), which also uses cursors that point between elements. The `peek_next` method returns a helper that lets you look at and optionally remove the element, as one common use-case of cursors is to iterate a list to look for an element, then remove that element. For many of the methods, this will reduce how many we need since they now just need a prev/next method, instead of the current state where you may end up needing all of curr/prev/next. Also, if we decide to add a function for splitting a list into two lists at the cursor, then a cursor that points between elements is exactly what makes the most sense. Another advantage is that this means you can now have a cursor into an empty list. Link: https://rust-unofficial.github.io/too-many-lists/sixth-cursors-intro.html [1] Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250210-cursor-between-v7-2-36f0215181ed@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-08rust: list: extract common code for insertionAlice Ryhl
To prepare for a new cursor API that has the ability to insert elements into the list, extract the common code needed for this operation into a new `insert_inner` method. Both `push_back` and `push_front` are updated to use the new function. Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250210-cursor-between-v7-1-36f0215181ed@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-08rust: lockdep: Use Pin for all LockClassKey usagesMitchell Levy
Reintroduce dynamically-allocated LockClassKeys such that they are automatically (de)registered. Require that all usages of LockClassKeys ensure that they are Pin'd. Currently, only `'static` LockClassKeys are supported, so Pin is redundant. However, it is intended that dynamically-allocated LockClassKeys will eventually be supported, so using Pin from the outset will make that change simpler. Closes: https://github.com/Rust-for-Linux/linux/issues/1102 Suggested-by: Benno Lossin <benno.lossin@proton.me> Suggested-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Mitchell Levy <levymitchell0@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Link: https://lore.kernel.org/r/20250307232717.1759087-12-boqun.feng@gmail.com
2025-03-08rust: sync: condvar: Add wait_interruptible_freezable()Alice Ryhl
To support waiting for a `CondVar` as a freezable process, add a wait_interruptible_freezable() function. Binder needs this function in the appropriate places to freeze a process where some of its threads are blocked on the Binder driver. [ Boqun: Cleaned up the changelog and documentation. ] Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20250307232717.1759087-10-boqun.feng@gmail.com
2025-03-08rust: sync: lock: Add an example for Guard:: Lock_ref()Boqun Feng
To provide examples on usage of `Guard::lock_ref()` along with the unit test, an "assert a lock is held by a guard" example is added. (Also apply feedback from Benno.) Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250223072114.3715-1-boqun.feng@gmail.com Link: https://lore.kernel.org/r/20250307232717.1759087-9-boqun.feng@gmail.com
2025-03-08rust: sync: Add accessor for the lock behind a given guardAlice Ryhl
In order to assert a particular `Guard` is associated with a particular `Lock`, add an accessor to obtain a reference to the underlying `Lock` of a `Guard`. Binder needs this assertion to ensure unsafe list operations are done with the correct lock held. [Boqun: Capitalize the title and reword the commit log] Signed-off-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Fiona Behrens <me@kloenk.dev> Link: https://lore.kernel.org/r/20250205-guard-get-lock-v2-1-ba32a8c1d5b7@google.com Link: https://lore.kernel.org/r/20250307232717.1759087-8-boqun.feng@gmail.com
2025-03-08rust: lockdep: Remove support for dynamically allocated LockClassKeysMitchell Levy
Currently, dynamically allocated LockCLassKeys can be used from the Rust side without having them registered. This is a soundness issue, so remove them. Fixes: 6ea5aa08857a ("rust: sync: introduce `LockClassKey`") Suggested-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Mitchell Levy <levymitchell0@gmail.com> Signed-off-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20250307232717.1759087-11-boqun.feng@gmail.com
2025-03-07rust: miscdevice: change how f_ops vtable is constructedAlice Ryhl
I was helping someone with writing a new Rust abstraction, and we were using the miscdevice abstraction as an example. While doing this, it became clear to me that the way I implemented the f_ops vtable is confusing to new Rust users, and that the approach used by the block abstractions is less confusing. Thus, update the miscdevice abstractions to use the same approach as rust/kernel/block/mq/operations.rs. Sorry about the large diff. This changes the indentation of a large amount of code. Reviewed-by: Christian Schrefl <chrisi.schrefl@gmail.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250227-miscdevice-fops-change-v1-1-c9e9b75d67eb@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-03-06rust: task: make Pid type alias publicAlice Ryhl
The Pid type alias represents the integer type used for pids in the kernel. It's the Rust equivalent to pid_t, and there are various methods on Task that use Pid as the return type. Binder needs to use Pid as the type for function arguments and struct fields in many places. Thus, make the type public so that Binder can access it. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Fiona Behrens <me@kloenk.dev> Link: https://lore.kernel.org/r/20250130-task-pid-pub-v1-1-508808bcfcdc@google.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-06rust: alloc: make `ReallocFunc::call` inlineGary Guo
This function can be called with different function pointers when different allocator (e.g. Kmalloc, Vmalloc, KVmalloc), however since this function is not polymorphic, only one instance is generated, and function pointers are used. Given that this function is called for any Rust-side allocation/deallocation, performance matters a lot, so making this function inlineable. This is discovered when doing helper inlining work, since it's discovered that even with helpers inlined, rust_helper_ symbols are still present in final vmlinux binary, and it turns out this function is inhibiting the inlining, and introducing indirect function calls. Signed-off-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250105194054.545201-4-gary@garyguo.net Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-06rust: workqueue: add missing newline to pr_info! examplesAlban Kurti
The documentation examples in rust/kernel/workqueue.rs use pr_info! calls that lack a trailing newline. To maintain consistency with kernel logging practices, this patch adds the newline to all affected examples. Fixes: 15b286d1fd05 ("rust: workqueue: add examples") Reported-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1139 Signed-off-by: Alban Kurti <kurti@invicto.ai> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250206-printing_fix-v3-5-a85273b501ae@invicto.ai [ Replaced Closes with Link since it fixes part of the issue. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-06rust: sync: add missing newline in locked_by log exampleAlban Kurti
The pr_info! example in rust/kernel/sync/locked_by.rs was missing a newline. This patch appends the missing newline to ensure that log messages for locked resources display correctly. Fixes: 7b1f55e3a984 ("rust: sync: introduce `LockedBy`") Reported-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1139 Signed-off-by: Alban Kurti <kurti@invicto.ai> Link: https://lore.kernel.org/r/20250206-printing_fix-v3-4-a85273b501ae@invicto.ai [ Replaced Closes with Link since it fixes part of the issue. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-06rust: init: add missing newline to pr_info! callsAlban Kurti
Several pr_info! calls in rust/kernel/init.rs (both in code examples and macro documentation) were missing a newline, causing logs to run together. This commit updates these calls to include a trailing newline, improving readability and consistency with the C side. Fixes: 6841d45a3030 ("rust: init: add `stack_pin_init!` macro") Fixes: 7f8977a7fe6d ("rust: init: add `{pin_}chain` functions to `{Pin}Init<T, E>`") Fixes: d0fdc3961270 ("rust: init: add `PinnedDrop` trait and macros") Fixes: 4af84c6a85c6 ("rust: init: update expanded macro explanation") Reported-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1139 Signed-off-by: Alban Kurti <kurti@invicto.ai> Link: https://lore.kernel.org/r/20250206-printing_fix-v3-3-a85273b501ae@invicto.ai [ Replaced Closes with Link since it fixes part of the issue. Added one more Fixes tag (still same set of stable kernels). - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-06rust: error: add missing newline to pr_warn! callsAlban Kurti
Added missing newline at the end of pr_warn! usage so the log is not missed. Fixes: 6551a7fe0acb ("rust: error: Add Error::from_errno{_unchecked}()") Reported-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1139 Signed-off-by: Alban Kurti <kurti@invicto.ai> Link: https://lore.kernel.org/r/20250206-printing_fix-v3-2-a85273b501ae@invicto.ai [ Replaced Closes with Link since it fixes part of the issue. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-05rust: alloc: satisfy POSIX alignment requirementTamir Duberstein
ISO C's `aligned_alloc` is partially implementation-defined; on some systems it inherits stricter requirements from POSIX's `posix_memalign`. This causes the call added in commit dd09538fb409 ("rust: alloc: implement `Cmalloc` in module allocator_test") to fail on macOS because it doesn't meet the requirements of `posix_memalign`. Adjust the call to meet the POSIX requirement and add a comment. This fixes failures in `make rusttest` on macOS. Acked-by: Danilo Krummrich <dakr@kernel.org> Cc: stable@vger.kernel.org Fixes: dd09538fb409 ("rust: alloc: implement `Cmalloc` in module allocator_test") Signed-off-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20250213-aligned-alloc-v7-1-d2a2d0be164b@gmail.com [ Added Cc: stable. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-05rust: init: fix `Zeroable` implementation for `Option<NonNull<T>>` and ↵Benno Lossin
`Option<KBox<T>>` According to [1], `NonNull<T>` and `#[repr(transparent)]` wrapper types such as our custom `KBox<T>` have the null pointer optimization only if `T: Sized`. Thus remove the `Zeroable` implementation for the unsized case. Link: https://doc.rust-lang.org/stable/std/option/index.html#representation [1] Reported-by: Alice Ryhl <aliceryhl@google.com> Closes: https://lore.kernel.org/rust-for-linux/CAH5fLghL+qzrD8KiCF1V3vf2YcC6aWySzkmaE2Zzrnh1gKj-hw@mail.gmail.com/ Cc: stable@vger.kernel.org # v6.12+ (a custom patch will be needed for 6.6.y) Fixes: 38cde0bd7b67 ("rust: init: add `Zeroable` trait and `init::zeroed` function") Signed-off-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250305132836.2145476-1-benno.lossin@proton.me [ Added Closes tag and moved up the Reported-by one. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-05rust: remove leftover mentions of the `alloc` crateMiguel Ojeda
In commit 392e34b6bc22 ("kbuild: rust: remove the `alloc` crate and `GlobalAlloc`") we stopped using the upstream `alloc` crate. Thus remove a few leftover mentions treewide. Cc: stable@vger.kernel.org # Also to 6.12.y after the `alloc` backport lands Fixes: 392e34b6bc22 ("kbuild: rust: remove the `alloc` crate and `GlobalAlloc`") Reviewed-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20250303171030.1081134-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-03-04cred,rust: mark Credential methods inlineAlice Ryhl
When you build the kernel using the llvm-19.1.4-rust-1.83.0-x86_64 toolchain provided by kernel.org with ARCH=arm64, the following symbols are generated: $ nm out-linux/vmlinux | grep ' _R'.*Credential | rustfilt ... T <kernel::cred::Credential>::get_secid ... T <kernel::cred::Credential as kernel::types::AlwaysRefCounted>::dec_ref ... T <kernel::cred::Credential as kernel::types::AlwaysRefCounted>::inc_ref However, these Rust symbols are trivial wrappers around the functions security_cred_getsecid, get_cred, and put_cred respectively. It doesn't make sense to go through a trivial wrapper for these functions, so mark them inline. Also mark other trivial methods inline to prevent similar cases in the future. After applying this patch, the above command will produce no output. Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> [PM: subject tweak, description line trims] Signed-off-by: Paul Moore <paul@paul-moore.com>
2025-03-04lsm,rust: reword "destroy" -> "release" in SecurityCtxAlice Ryhl
What happens inside the individual LSMs for a given LSM hook can vary quite a bit, so it is best to use the terminology "release" instead of "destroy" or "free". Suggested-by: Casey Schaufler <casey@schaufler-ca.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Casey Schaufler <casey@schaufler-ca.com> Reviewed-by: Fiona Behrens <me@kloenk.dev> [PM: subj tweak] Signed-off-by: Paul Moore <paul@paul-moore.com>
2025-03-04lsm,rust: mark SecurityCtx methods inlineAlice Ryhl
When you build the kernel using the llvm-19.1.4-rust-1.83.0-x86_64 toolchain provided by kernel.org with ARCH=arm64, the following symbols are generated: $ nm vmlinux | grep ' _R'.*SecurityCtx | rustfilt ... T <kernel::security::SecurityCtx>::from_secid ... T <kernel::security::SecurityCtx as core::ops::drop::Drop>::drop However, these Rust symbols are trivial wrappers around the functions security_secid_to_secctx and security_release_secctx respectively. It doesn't make sense to go through a trivial wrapper for these functions, so mark them inline. Also mark other trivial methods inline to prevent similar cases in the future. After applying this patch, the above command will produce no output. Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Fiona Behrens <me@kloenk.dev> [PM: trimmed long description lines, subj tweak] Signed-off-by: Paul Moore <paul@paul-moore.com>
2025-02-28rust: Add cpumask helpersViresh Kumar
In order to prepare for adding Rust abstractions for cpumask, add the required helpers for inline cpumask functions that cannot be called by rust code directly. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Yury Norov [NVIDIA] <yury.norov@gmail.com>
2025-02-27rust/faux: Add missing parent argument to Registration::new()Lyude Paul
A little late in the review of the faux device interface, we added the ability to specify a parent device when creating new faux devices - but this never got ported over to the rust bindings. So, let's add the missing argument now so we don't have to convert other users later down the line. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250227193522.198344-1-lyude@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-27rust/faux: Drop #[repr(transparent)] from faux::RegistrationLyude Paul
I think this change got missed during review, we don't need #[repr(transparent)] since Registration just holds a single NonNull. This attribute had originally been added by me when I was still figuring out how the bindings should look like but got committed by mistake. So, just drop it. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Fiona Behrens <me@Kloenk.dev> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250225213112.872264-2-lyude@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-25rust: io: fix devres test with new io accessor functionsFiona Behrens
Fix doctest of `Devres` which still used `writeb` instead of `write8`. Fixes: 354fd6e86fac ("rust: io: rename `io::Io` accessors") Signed-off-by: Fiona Behrens <me@kloenk.dev> Link: https://lore.kernel.org/r/20250224-rust-iowrite-read8-fix-v1-1-c6abee346897@kloenk.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-24rust: workqueue: define built-in bh queuesHamza Mahfooz
Provide safe getters to the system bh work queues. They will be used to reimplement the Hyper-V VMBus in rust. Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2025-02-22rust: io: rename `io::Io` accessorsFiona Behrens
Rename the I/O accessors provided by `Io` to encode the type as number instead of letter. This is in preparation for Port I/O support to use a trait for generic accessors. Add a `c_fn` argument to the accessor generation macro to translate between rust and C names. Suggested-by: Danilo Krummrich <dakr@kernel.org> Link: https://rust-for-linux.zulipchat.com/#narrow/channel/288089-General/topic/PIO.20support/near/499460541 Signed-off-by: Fiona Behrens <me@kloenk.dev> Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Daniel Almeida <daniel.almeida@collabora.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250217-io-generic-rename-v1-1-06d97a9e3179@kloenk.dev Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-16Merge tag 'driver-core-6.14-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core api addition from Greg KH: "Here is a driver core new api for 6.14-rc3 that is being added to allow platform devices from stop being abused. It adds a new 'faux_device' structure and bus and api to allow almost a straight or simpler conversion from platform devices that were not really a platform device. It also comes with a binding for rust, with an example driver in rust showing how it's used. I'm adding this now so that the patches that convert the different drivers and subsystems can all start flowing into linux-next now through their different development trees, in time for 6.15-rc1. We have a number that are already reviewed and tested, but adding those conversions now doesn't seem right. For now, no one is using this, and it passes all build tests from 0-day and linux-next, so all should be good" * tag 'driver-core-6.14-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: rust/kernel: Add faux device bindings driver core: add a faux bus for use when a simple device/bus is needed
2025-02-13rust/kernel: Add faux device bindingsLyude Paul
This introduces a module for working with faux devices in rust, along with adding sample code to show how the API is used. Unlike other types of devices, we don't provide any hooks for device probe/removal - since these are optional for the faux API and are unnecessary in rust. Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Maíra Canal <mairacanal@riseup.net> Cc: Danilo Krummrich <dakr@kernel.org> Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/2025021026-exert-accent-b4c6@gregkh Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-02-12rust: rbtree: fix overindented list itemMiguel Ojeda
Starting with Rust 1.86.0 (to be released 2025-04-03), Clippy will have a new lint, `doc_overindented_list_items` [1], which catches cases of overindented list items. The lint has been added by Yutaro Ohno, based on feedback from the kernel [2] on a patch that fixed a similar case -- commit 0c5928deada1 ("rust: block: fix formatting in GenDisk doc"). Clippy reports a few cases in the kernel, apart from the one already fixed in the commit above. One is this one: error: doc list item overindented --> rust/kernel/rbtree.rs:1152:5 | 1152 | /// null, it is a pointer to the root of the [`RBTree`]. | ^^^^ help: try using ` ` (2 spaces) | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_overindented_list_items = note: `-D clippy::doc-overindented-list-items` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::doc_overindented_list_items)]` Thus clean it up. Cc: Yutaro Ohno <yutaro.ono.418@gmail.com> Cc: stable@vger.kernel.org # Needed in 6.12.y and 6.13.y only (Rust is pinned in older LTSs). Fixes: a335e9591404 ("rust: rbtree: add `RBTree::entry`") Link: https://github.com/rust-lang/rust-clippy/pull/13711 [1] Link: https://github.com/rust-lang/rust-clippy/issues/13601 [2] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Yutaro Ohno <yutaro.ono.418@gmail.com> Link: https://lore.kernel.org/r/20250206232022.599998-1-ojeda@kernel.org [ There are a few other cases, so updated message. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-02-06rust: kbuild: do not export generated KASAN ODR symbolsMatthew Maurer
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 <mmaurer@google.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250122-gendwarfksyms-kasan-rust-v1-1-5ee5658f4fb6@google.com [ Fixed typo in commit message. Slightly reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-02-06rust: kbuild: add -fzero-init-padding-bits to bindgen_skip_cflagsJustin M. Forbes
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 <jforbes@fedoraproject.org> Fixes: dce4aab8441d ("kbuild: Use -fzero-init-padding-bits=all") Reviewed-by: Kees Cook <kees@kernel.org> Link: https://lore.kernel.org/r/20250129215003.1736127-1-jforbes@fedoraproject.org [ Slightly reworded commit. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-02-06rust: init: use explicit ABI to clean warning in future compilersMiguel Ojeda
Starting with Rust 1.86.0 (currently in nightly, to be released on 2025-04-03), the `missing_abi` lint is warn-by-default [1]: error: extern declarations without an explicit ABI are deprecated --> rust/doctests_kernel_generated.rs:3158:1 | 3158 | extern { | ^^^^^^ help: explicitly specify the C ABI: `extern "C"` | = note: `-D missing-abi` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(missing_abi)]` Thus clean it up. Cc: <stable@vger.kernel.org> # Needed in 6.12.y and 6.13.y only (Rust is pinned in older LTSs). Fixes: 7f8977a7fe6d ("rust: init: add `{pin_}chain` functions to `{Pin}Init<T, E>`") Link: https://github.com/rust-lang/rust/pull/132397 [1] Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Fiona Behrens <me@kloenk.dev> Link: https://lore.kernel.org/r/20250121200934.222075-1-ojeda@kernel.org [ Added 6.13.y to Cc: stable tag. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-02-06rust: kbuild: use host dylib naming in rusttestlib-kernelTamir Duberstein
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 <tamird@gmail.com> Link: https://lore.kernel.org/r/20250201-fix-mac-build-again-v1-1-ca665f5d7de7@gmail.com [ Slightly reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-01-31Merge tag 'kbuild-v6.14' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild updates from Masahiro Yamada: - Support multiple hook locations for maint scripts of Debian package - Remove 'cpio' from the build tool requirement - Introduce gendwarfksyms tool, which computes CRCs for export symbols based on the DWARF information - Support CONFIG_MODVERSIONS for Rust - Resolve all conflicts in the genksyms parser - Fix several syntax errors in genksyms * tag 'kbuild-v6.14' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (64 commits) kbuild: fix Clang LTO with CONFIG_OBJTOOL=n kbuild: Strip runtime const RELA sections correctly kconfig: fix memory leak in sym_warn_unmet_dep() kconfig: fix file name in warnings when loading KCONFIG_DEFCONFIG_LIST genksyms: fix syntax error for attribute before init-declarator genksyms: fix syntax error for builtin (u)int*x*_t types genksyms: fix syntax error for attribute after 'union' genksyms: fix syntax error for attribute after 'struct' genksyms: fix syntax error for attribute after abstact_declarator genksyms: fix syntax error for attribute before nested_declarator genksyms: fix syntax error for attribute before abstract_declarator genksyms: decouple ATTRIBUTE_PHRASE from type-qualifier genksyms: record attributes consistently for init-declarator genksyms: restrict direct-declarator to take one parameter-type-list genksyms: restrict direct-abstract-declarator to take one parameter-type-list genksyms: remove Makefile hack genksyms: fix last 3 shift/reduce conflicts genksyms: fix 6 shift/reduce conflicts and 5 reduce/reduce conflicts genksyms: reduce type_qualifier directly to decl_specifier genksyms: rename cvar_qualifier to type_qualifier ...