summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-11-25rust: alloc: Fix `ArrayLayout` allocationsAsahi Lina
We were accidentally allocating a layout for the *square* of the object size due to a variable shadowing mishap. Fixes memory bloat and page allocation failures in drm/asahi. Reported-by: Janne Grunau <j@jannau.net> Fixes: 9e7bbfa18276 ("rust: alloc: introduce `ArrayLayout`") Signed-off-by: Asahi Lina <lina@asahilina.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Neal Gompa <neal@gompa.dev> Link: https://lore.kernel.org/r/20241123-rust-fix-arraylayout-v1-1-197e64c95bd4@asahilina.net Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-25docs: rust: remove spurious item in `expect` listMiguel Ojeda
This list started as a "when to prefer `expect`" list, but at some point during writing I changed it to a "prefer `expect` unless..." one. However, the first bullet remained, which does not make sense anymore. Thus remove it. In addition, fix nearby typo. Fixes: 04866494e936 ("Documentation: rust: discuss `#[expect(...)]` in the guidelines") Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20241117133127.473937-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-25rust: allow `clippy::needless_lifetimes`Miguel Ojeda
In beta Clippy (i.e. Rust 1.83.0), the `needless_lifetimes` lint has been extended [1] to suggest eliding `impl` lifetimes, e.g. error: the following explicit lifetimes could be elided: 'a --> rust/kernel/list.rs:647:6 | 647 | impl<'a, T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'a, T, ID> {} | ^^ ^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_lifetimes = note: `-D clippy::needless-lifetimes` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::needless_lifetimes)]` help: elide the lifetimes | 647 - impl<'a, T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'a, T, ID> {} 647 + impl<T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'_, T, ID> {} A possibility would have been to clean them -- the RFC patch [2] did this, while asking if we wanted these cleanups. There is an open issue [3] in Clippy about being able to differentiate some of the new cases, e.g. those that do not involve introducing `'_`. Thus it seems others feel similarly. Thus, for the time being, we decided to `allow` the lint. Link: https://github.com/rust-lang/rust-clippy/pull/13286 [1] Link: https://lore.kernel.org/rust-for-linux/20241012231300.397010-1-ojeda@kernel.org/ [2] Link: https://github.com/rust-lang/rust-clippy/issues/13514 [3] Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20241116181538.369355-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-12rust: warn on bindgen < 0.69.5 and libclang >= 19.1Miguel Ojeda
When testing a `clang` upgrade with Rust Binder, Alice encountered [1] a build failure caused by `bindgen` not translating some symbols related to tracepoints. This was caused by commit 2e770edd8ce1 ("[libclang] Compute the right spelling location") changing the behavior of a function exposed by `libclang`. `bindgen` fixed the regression in commit 600f63895f73 ("Use clang_getFileLocation instead of clang_getSpellingLocation"). However, the regression fix is only available in `bindgen` versions 0.69.5 or later (it was backported for 0.69.x). This means that when older bindgen versions are used with new versions of `libclang`, `bindgen` may do the wrong thing, which could lead to a build failure. Alice encountered the bug with some header files related to tracepoints, but it could also cause build failures in other circumstances. Thus, always emit a warning when using an old `bindgen` with a new `libclang` so that other people do not have to spend time chasing down the same bug. However, testing just the version is inconvenient, since distributions do patch their packages without changing the version, so I reduced the issue into the following piece of code that can trigger the issue: #define F(x) int x##x F(foo); In particular, an unpatched `bindgen` will ignore the macro expansion and thus not provide a declaration for the exported `int`. Thus add a build test to `rust_is_available.sh` using the code above (that is only triggered if the versions appear to be affected), following what we did for the 0.66.x issue. Moreover, I checked the status in the major distributions we have instructions for: - Fedora 41 was affected but is now OK, since it now ships `bindgen` 0.69.5. Thanks Ben for the quick reply on the updates that were ongoing. Fedora 40 and earlier are OK (older `libclang`, and they also now carry `bindgen` 0.69.5). - Debian Sid was affected but is now OK, since they now ship a patched `bindgen` binary (0.66.1-7+b3). The issue was reported to Debian by email and then as a bug report [2]. Thanks NoisyCoil and Matthias for the quick replies. NoisyCoil handled the needed updates. Debian may upgrade to `bindgen` 0.70.x, too. Debian Testing is OK (older `libclang` so far). - Ubuntu non-LTS (oracular) is affected. The issue was reported to Ubuntu by email and then as a bug report [3]. Ubuntu LTS is not affected (older `libclang` so far). - Arch Linux, Gentoo Linux and openSUSE should be OK (newer `bindgen` is provided). Nix as well (older `libclang` so far). This issue was also added to our "live list" that tracks issues around distributions [4]. Cc: Ben Beasley <code@musicinmybrain.net> Cc: NoisyCoil <noisycoil@tutanota.com> Cc: Matthias Geiger <werdahias@riseup.net> Link: https://lore.kernel.org/rust-for-linux/20241030-bindgen-libclang-warn-v1-1-3a7ba9fedcfe@google.com/ [1] Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086510 [2] Link: https://bugs.launchpad.net/ubuntu/+source/rust-bindgen-cli/+bug/2086639 [3] Link: https://github.com/Rust-for-Linux/linux/issues/1127 [4] Co-developed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20241111201607.653149-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-10rust: use custom FFI integer typesGary Guo
Currently FFI integer types are defined in libcore. This commit creates the `ffi` crate and asks bindgen to use that crate for FFI integer types instead of `core::ffi`. This commit is preparatory and no type changes are made in this commit yet. Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240913213041.395655-4-gary@garyguo.net [ Added `rustdoc`, `rusttest` and KUnit tests support. Rebased on top of `rust-next` (e.g. migrated more `core::ffi` cases). Reworded crate docs slightly and formatted. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-10rust: map `__kernel_size_t` and friends also to usize/isizeGary Guo
Currently bindgen has special logic to recognise `size_t` and `ssize_t` and map them to Rust `usize` and `isize`. Similarly, `ptrdiff_t` is mapped to `isize`. However this falls short for `__kernel_size_t`, `__kernel_ssize_t` and `__kernel_ptrdiff_t`. To ensure that they are mapped to usize/isize rather than 32/64 integers depending on platform, blocklist them in bindgen parameters and manually provide their definition. Signed-off-by: Gary Guo <gary@garyguo.net> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Trevor Gross <tmgross@umich.edu> Link: https://lore.kernel.org/r/20240913213041.395655-3-gary@garyguo.net [ Formatted comment. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-10rust: fix size_t in bindgen prototypes of C builtinsGary Guo
Without `-fno-builtin`, for functions like memcpy/memmove (and many others), bindgen seems to be using the clang-provided prototype. This prototype is ABI-wise compatible, but the issue is that it does not have the same information as the source code w.r.t. typedefs. For example, bindgen generates the following: extern "C" { pub fn strlen(s: *const core::ffi::c_char) -> core::ffi::c_ulong; } note that the return type is `c_ulong` (i.e. unsigned long), despite the size_t-is-usize behavior (this is default, and we have not opted out from it using --no-size_t-is-usize). Similarly, memchr's size argument should be of type `__kernel_size_t`, but bindgen generates `c_ulong` directly. We want to ensure any `size_t` is translated to Rust `usize` so that we can avoid having them be different type on 32-bit and 64-bit architectures, and hence would require a lot of excessive type casts when calling FFI functions. I found that this bindgen behavior (which probably is caused by libclang) can be disabled by `-fno-builtin`. Using the flag for compiled code can result in less optimisation because compiler cannot assume about their properties anymore, but this should not affect bindgen. [ Trevor asked: "I wonder how reliable this behavior is. Maybe bindgen could do a better job controlling this, is there an open issue?". Gary replied: ..."apparently this is indeed the suggested approach in https://github.com/rust-lang/rust-bindgen/issues/1770". - Miguel ] Signed-off-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/r/20240913213041.395655-2-gary@garyguo.net [ Formatted comment. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-10rust: sync: add global lock supportAlice Ryhl
Add support for creating global variables that are wrapped in a mutex or spinlock. The implementation here is intended to replace the global mutex workaround found in the Rust Binder RFC [1]. In both cases, the global lock must be initialized before first use. The macro is unsafe to use for the same reason. The separate initialization step is required because it is tricky to access the value of __ARCH_SPIN_LOCK_UNLOCKED from Rust. Doing so will require changes to the C side. That change will happen as a follow-up to this patch. Link: https://lore.kernel.org/rust-for-linux/20231101-rust-binder-v1-2-08ba9197f637@google.com/#Z31drivers:android:context.rs [1] Signed-off-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Link: https://lore.kernel.org/r/20241023-static-mutex-v6-1-d7efdadcc84f@google.com [ Simplified a few intra-doc links. Formatted a few comments. Reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-01rust: macros: enable the rest of the testsEthan D. Twardy
Now that the rusttest target for the macros crate is compiled with the kernel crate as a dependency, the rest of the rustdoc tests can be enabled. Signed-off-by: Ethan D. Twardy <ethan.twardy@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://github.com/Rust-for-Linux/linux/issues/1076 Link: https://lore.kernel.org/r/20240704145607.17732-5-ethan.twardy@gmail.com [ Rebased (use `K{Box,Vec}` instead, enable `lint_reasons` feature). Remove unneeded `rust` as language in examples, as well as `#[macro_use]` `extern`s. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-01rust: macros: enable paste! use from macro_rules!Ethan D. Twardy
According to the rustdoc for the proc_macro crate[1], tokens captured from a "macro variable" (e.g. from within macro_rules!) may be delimited by invisible tokens and be contained within a proc_macro::Group. Previously, this scenario was not handled by macros::paste, which caused a proc-macro panic when the corresponding tests are enabled. Enable the tests, and handle this case by making macros::paste::concat recursive. Link: https://doc.rust-lang.org/stable/proc_macro/enum.Delimiter.html [1] Signed-off-by: Ethan D. Twardy <ethan.twardy@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://github.com/Rust-for-Linux/linux/issues/1076 Link: https://lore.kernel.org/r/20240704145607.17732-4-ethan.twardy@gmail.com [ Rebased (one fix was already applied) and reworded. Remove unneeded `rust` as language in examples. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-01rust: enable macros::module! testsEthan D. Twardy
Previously, these tests were ignored due to a missing necessary dependency on the `kernel` crate. Enable the tests, and update them: for both, add the parameter to `init()`; for the first one, remove the use of a kernel parameter mechanism that was never merged. Signed-off-by: Ethan D. Twardy <ethan.twardy@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://github.com/Rust-for-Linux/linux/issues/1076 Link: https://lore.kernel.org/r/20240704145607.17732-3-ethan.twardy@gmail.com [ Rebased (moved the `export` to the `rustdoc_test` rule, enable the firmware example too). Removed `export` for `RUST_MODFILE`. Removed unneeded `rust` language in examples, as well as `#[macro_use]` `extern`s. Reworded accordingly. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-01rust: kbuild: expand rusttest target for macrosEthan D. Twardy
Previously, the rusttest target for the macros crate did not specify the dependencies necessary to run the rustdoc tests. These tests rely on the kernel crate, so add the dependencies. Signed-off-by: Ethan D. Twardy <ethan.twardy@gmail.com> Link: https://github.com/Rust-for-Linux/linux/issues/1076 Link: https://lore.kernel.org/r/20240704145607.17732-2-ethan.twardy@gmail.com [ Rebased (`alloc` is gone nowadays, sysroot handling is simpler) and simplified (reused `rustdoc_test` rule instead of adding a new one, no need for `rustdoc-compiler_builtins`, removed unneeded `macros` explicit path). Made `vtable` example fail (avoiding to increase the complexity in the `rusttest` target). Removed unstable `-Zproc-macro-backtrace` option. Reworded accordingly. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-24rust: types: extend `Opaque` documentationDirk Behme
Update the `Opaque` documentation and add an example as proposed by Miguel Ojeda in [1]. The documentation update is mainly taken from Benno Lossin's description [2]. Cc: Nell Shamrell-Harrington <nells@linux.microsoft.com> Suggested-by: Miguel Ojeda <ojeda@kernel.org> Link: https://rust-for-linux.zulipchat.com/#narrow/stream/291565/topic/x/near/467478085 [1] Link: https://rust-for-linux.zulipchat.com/#narrow/stream/291565/topic/x/near/470498289 [2] Co-developed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Dirk Behme <dirk.behme@de.bosch.com> Link: https://lore.kernel.org/r/20241002050301.1927545-1-dirk.behme@de.bosch.com [ Used `expect`. Rewrapped docs. Added intra-doc link. Formatted example. Reworded to fix tag typo/order. Fixed `&mut` formatting as discussed. Added Benno's SOB and CDB as discussed. Shortened links. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-22rust: block: fix formatting of `kernel::block::mq::request` moduleFrancesco Zardi
Fix several issues with rustdoc formatting for the `kernel::block::mq::Request` module, in particular: - An ordered list not rendering correctly, fixed by using numbers prefixes instead of letters. - Code snippets formatted as regular text, fixed by wrapping the code with `back-ticks`. - References to types missing intra-doc links, fixed by wrapping the types with [square brackets]. Reported-by: Miguel Ojeda <ojeda@kernel.org> Closes: https://github.com/Rust-for-Linux/linux/issues/1108 Signed-off-by: Francesco Zardi <frazar00@gmail.com> Acked-by: Andreas Hindborg <a.hindborg@kernel.org> Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module") Link: https://lore.kernel.org/r/20240903173027.16732-3-frazar00@gmail.com [ Added an extra intra-doc link. Took the chance to add some periods for consistency. Reworded slightly. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-21rust: macros: fix documentation of the paste! macroPaolo Bonzini
One of the example in this section uses a curious mix of the constant and function declaration syntaxes; fix it. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Fixes: 823d4737d4c2 ("rust: macros: add `paste!` proc macro") Link: https://lore.kernel.org/r/20241019072208.1016707-1-pbonzini@redhat.com Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-21rust: kernel: fix THIS_MODULE header path in ThisModule doc commentYutaro Ohno
The doc comment for `ThisModule` incorrectly states the C header file for `THIS_MODULE` as `include/linux/export.h`, while the correct path is `include/linux/init.h`. This is because `THIS_MODULE` was moved in commit 5b20755b7780 ("init: move THIS_MODULE from <linux/export.h> to <linux/init.h>"). Update the doc comment for `ThisModule` to reflect the correct header file path for `THIS_MODULE`. Fixes: 5b20755b7780 ("init: move THIS_MODULE from <linux/export.h> to <linux/init.h>") Signed-off-by: Yutaro Ohno <yutaro.ono.418@gmail.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/ZxXDZwxWgoEiIYkj@ohnotp Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-21rust: page: add Rust version of PAGE_ALIGNAlice Ryhl
This is a useful for helper for working with indices into buffers that consist of several pages. I forgot to include it when I added PAGE_SIZE and PAGE_MASK for the same purpose in commit fc6e66f4696b ("rust: add abstraction for `struct page`"). Reviewed-by: Boqun Feng <boqun.feng@gmail.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20241016-page-align-v2-1-e0afe85fc4b4@google.com [ Added intra-doc links, formatted comment and replaced "Brackets" with "Parentheses" as discussed in the list. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-21rust: helpers: remove unnecessary header includesTamir Duberstein
Commit e26fa546042a ("rust: kbuild: auto generate helper exports") removed the need for these by automatically generating the exports; it removed the explicit uses of `EXPORT_SYMBOL_GPL` but didn't remove the `#include <linux/export.h>`s. Signed-off-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20241009162553.27845-2-tamird@gmail.com [ Reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-21rust: exports: improve grammar in commentaryTamir Duberstein
Commit e26fa546042a ("rust: kbuild: auto generate helper exports") added an errant "the" where one was not needed; remove it. Signed-off-by: Tamir Duberstein <tamird@gmail.com> Reviewed-by: Dirk Behme <dirk.behme@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org> Link: https://lore.kernel.org/r/20241009162358.27735-1-tamird@gmail.com [ Reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-20drm/panic: allow verbose version checkThomas Böhler
Clippy warns about a reimplementation of `RangeInclusive::contains`: error: manual `!RangeInclusive::contains` implementation --> drivers/gpu/drm/drm_panic_qr.rs:986:8 | 986 | if version < 1 || version > 40 { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: use: `!(1..=40).contains(&version)` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#manual_range_contains = note: `-D clippy::manual-range-contains` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::manual_range_contains)]` Ignore this and keep the current implementation as that makes it easier to read. Fixes: cb5164ac43d0 ("drm/panic: Add a QR code panic screen") Reported-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1123 Signed-off-by: Thomas Böhler <witcher@wiredspace.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20241019084048.22336-8-witcher@wiredspace.de Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-20drm/panic: allow verbose boolean for clarityThomas Böhler
Clippy complains about a non-minimal boolean expression with `nonminimal_bool`: error: this boolean expression can be simplified --> drivers/gpu/drm/drm_panic_qr.rs:722:9 | 722 | (x < 8 && y < 8) || (x < 8 && y >= end) || (x >= end && y < 8) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#nonminimal_bool = note: `-D clippy::nonminimal-bool` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::nonminimal_bool)]` help: try | 722 | !(x >= 8 || y >= 8 && y < end) || (x >= end && y < 8) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 722 | (y >= end || y < 8) && x < 8 || (x >= end && y < 8) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ While this can be useful in a lot of cases, it isn't here because the line expresses clearly what the intention is. Simplifying the expression means losing clarity, so opt-out of this lint for the offending line. Fixes: cb5164ac43d0 ("drm/panic: Add a QR code panic screen") Reported-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1123 Signed-off-by: Thomas Böhler <witcher@wiredspace.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20241019084048.22336-7-witcher@wiredspace.de Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-20drm/panic: correctly indent continuation of line in list itemThomas Böhler
It is common practice in Rust to indent the next line the same amount of space as the previous one if both belong to the same list item. Clippy checks for this with the lint `doc_lazy_continuation`. error: doc list item without indentation --> drivers/gpu/drm/drm_panic_qr.rs:979:5 | 979 | /// conversion to numeric segments. | ^ | = help: if this is supposed to be its own paragraph, add a blank line = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#doc_lazy_continuation = note: `-D clippy::doc-lazy-continuation` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::doc_lazy_continuation)]` help: indent this line | 979 | /// conversion to numeric segments. | ++ Indent the offending line by 2 more spaces to remove this Clippy error. Fixes: cb5164ac43d0 ("drm/panic: Add a QR code panic screen") Reported-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1123 Signed-off-by: Thomas Böhler <witcher@wiredspace.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20241019084048.22336-6-witcher@wiredspace.de [ Reworded to indent Clippy's message. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-20drm/panic: remove redundant field when assigning valueThomas Böhler
Rust allows initializing fields of a struct without specifying the attribute that is assigned if the variable has the same name. In this instance this is done for all other attributes of the struct except for `data`. Clippy notes the redundant field name: error: redundant field names in struct initialization --> drivers/gpu/drm/drm_panic_qr.rs:495:13 | 495 | data: data, | ^^^^^^^^^^ help: replace it with: `data` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#redundant_field_names = note: `-D clippy::redundant-field-names` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::redundant_field_names)]` Remove the redundant `data` in the assignment to be consistent. Fixes: cb5164ac43d0 ("drm/panic: Add a QR code panic screen") Reported-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1123 Signed-off-by: Thomas Böhler <witcher@wiredspace.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20241019084048.22336-5-witcher@wiredspace.de [ Reworded to add Clippy warning like it is done in the rest of the series. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-20drm/panic: prefer eliding lifetimesThomas Böhler
Eliding lifetimes when possible instead of specifying them directly is both shorter and easier to read. Clippy notes this in the `needless_lifetimes` lint: error: the following explicit lifetimes could be elided: 'b --> drivers/gpu/drm/drm_panic_qr.rs:479:16 | 479 | fn new<'a, 'b>(segments: &[&Segment<'b>], data: &'a mut [u8]) -> Option<EncodedMsg<'a>> { | ^^ ^^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_lifetimes = note: `-D clippy::needless-lifetimes` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::needless_lifetimes)]` help: elide the lifetimes | 479 - fn new<'a, 'b>(segments: &[&Segment<'b>], data: &'a mut [u8]) -> Option<EncodedMsg<'a>> { 479 + fn new<'a>(segments: &[&Segment<'_>], data: &'a mut [u8]) -> Option<EncodedMsg<'a>> { | Remove the explicit lifetime annotation in favour of an elided lifetime. Fixes: cb5164ac43d0 ("drm/panic: Add a QR code panic screen") Reported-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1123 Signed-off-by: Thomas Böhler <witcher@wiredspace.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20241019084048.22336-4-witcher@wiredspace.de Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-20drm/panic: remove unnecessary borrow in alignment_patternThomas Böhler
The function `alignment_pattern` returns a static reference to a `u8` slice. The borrow of the returned element in `ALIGNMENT_PATTERNS` is already a reference as defined in the array definition above so this borrow is unnecessary and removed by the compiler. Clippy notes this in `needless_borrow`: error: this expression creates a reference which is immediately dereferenced by the compiler --> drivers/gpu/drm/drm_panic_qr.rs:245:9 | 245 | &ALIGNMENT_PATTERNS[self.0 - 1] | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: change this to: `ALIGNMENT_PATTERNS[self.0 - 1]` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_borrow = note: `-D clippy::needless-borrow` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::needless_borrow)]` Remove the unnecessary borrow. Fixes: cb5164ac43d0 ("drm/panic: Add a QR code panic screen") Reported-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1123 Signed-off-by: Thomas Böhler <witcher@wiredspace.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20241019084048.22336-3-witcher@wiredspace.de Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-20drm/panic: avoid reimplementing Iterator::findThomas Böhler
Rust's standard library's `std::iter::Iterator` trait provides a function `find` that finds the first element that satisfies a predicate. The function `Version::from_segments` is doing the same thing but is implementing the same logic itself. Clippy complains about this in the `manual_find` lint: error: manual implementation of `Iterator::find` --> drivers/gpu/drm/drm_panic_qr.rs:212:9 | 212 | / for v in (1..=40).map(|k| Version(k)) { 213 | | if v.max_data() * 8 >= segments.iter().map(|s| s.total_size_bits(v)).sum() { 214 | | return Some(v); 215 | | } 216 | | } 217 | | None | |____________^ help: replace with an iterator: `(1..=40).map(|k| Version(k)).find(|&v| v.max_data() * 8 >= segments.iter().map(|s| s.total_size_bits(v)).sum())` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#manual_find = note: `-D clippy::manual-find` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::manual_find)]` Use `Iterator::find` instead to make the intention clearer. At the same time, clean up the redundant closure that Clippy warns about too: error: redundant closure --> drivers/gpu/drm/drm_panic_qr.rs:212:31 | 212 | for v in (1..=40).map(|k| Version(k)) { | ^^^^^^^^^^^^^^ help: replace the closure with the function itself: `Version` | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#redundant_closure = note: `-D clippy::redundant-closure` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::redundant_closure)]` Fixes: cb5164ac43d0 ("drm/panic: Add a QR code panic screen") Reported-by: Miguel Ojeda <ojeda@kernel.org> Link: https://github.com/Rust-for-Linux/linux/issues/1123 Signed-off-by: Thomas Böhler <witcher@wiredspace.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://lore.kernel.org/r/20241019084048.22336-2-witcher@wiredspace.de [ Reworded to mention the redundant closure cleanup too. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15MAINTAINERS: add entry for the Rust `alloc` moduleDanilo Krummrich
Add maintainers entry for the Rust `alloc` module. Currently, this includes the `Allocator` API itself, `Allocator` implementations, such as `Kmalloc` or `Vmalloc`, as well as the kernel's implementation of the primary memory allocation data structures, `Box` and `Vec`. Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-30-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15kbuild: rust: remove the `alloc` crate and `GlobalAlloc`Danilo Krummrich
Now that we have our own `Allocator`, `Box` and `Vec` types we can remove Rust's `alloc` crate and the `new_uninit` unstable feature. Also remove `Kmalloc`'s `GlobalAlloc` implementation -- we can't remove this in a separate patch, since the `alloc` crate requires a `#[global_allocator]` to set, that implements `GlobalAlloc`. Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-29-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: alloc: update module comment of alloc.rsDanilo Krummrich
Before we remove Rust's alloc crate, rewrite the module comment in alloc.rs to avoid a rustdoc warning. Besides that, the module comment in alloc.rs isn't correct anymore, we're no longer extending Rust's alloc crate. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-28-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: str: test: replace `alloc::format`Danilo Krummrich
The current implementation of tests in str.rs use `format!` to format strings for comparison, which, internally, creates a new `String`. In order to prepare for getting rid of Rust's alloc crate, we have to cut this dependency. Instead, implement `format!` for `CString`. Note that for userspace tests, `Kmalloc`, which is backing `CString`'s memory, is just a type alias to `Cmalloc`. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-27-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: alloc: implement `Cmalloc` in module allocator_testDanilo Krummrich
So far the kernel's `Box` and `Vec` types can't be used by userspace test cases, since all users of those types (e.g. `CString`) use kernel allocators for instantiation. In order to allow userspace test cases to make use of such types as well, implement the `Cmalloc` allocator within the allocator_test module and type alias all kernel allocators to `Cmalloc`. The `Cmalloc` allocator uses libc's `realloc()` function as allocator backend. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-26-dakr@kernel.org [ Removed the temporary `allow(dead_code)` as discussed in the list and fixed typo, added backticks. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: alloc: implement `contains` for `Flags`Danilo Krummrich
Provide a simple helper function to check whether given flags do contain one or multiple other flags. This is used by a subsequent patch implementing the Cmalloc `Allocator` to check for __GFP_ZERO. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-25-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: error: check for config `test` in `Error::name`Danilo Krummrich
Additional to `testlib` also check for `test` in `Error::name`. This is required by a subsequent patch that (indirectly) uses `Error` in test cases. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-24-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: error: use `core::alloc::LayoutError`Danilo Krummrich
Use `core::alloc::LayoutError` instead of `alloc::alloc::LayoutError` in preparation to get rid of Rust's alloc crate. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-23-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: alloc: add `Vec` to preludeDanilo Krummrich
Now that we removed `VecExt` and the corresponding includes in prelude.rs, add the new kernel `Vec` type instead. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-22-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: alloc: remove `VecExt` extensionDanilo Krummrich
Now that all existing `Vec` users were moved to the kernel `Vec` type, remove the `VecExt` extension. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-21-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: treewide: switch to the kernel `Vec` typeDanilo Krummrich
Now that we got the kernel `Vec` in place, convert all existing `Vec` users to make use of it. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-20-dakr@kernel.org [ Converted `kasan_test_rust.rs` too, as discussed. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: alloc: implement `collect` for `IntoIter`Danilo Krummrich
Currently, we can't implement `FromIterator`. There are a couple of issues with this trait in the kernel, namely: - Rust's specialization feature is unstable. This prevents us to optimize for the special case where `I::IntoIter` equals `Vec`'s `IntoIter` type. - We also can't use `I::IntoIter`'s type ID either to work around this, since `FromIterator` doesn't require this type to be `'static`. - `FromIterator::from_iter` does return `Self` instead of `Result<Self, AllocError>`, hence we can't properly handle allocation failures. - Neither `Iterator::collect` nor `FromIterator::from_iter` can handle additional allocation flags. Instead, provide `IntoIter::collect`, such that we can at least convert `IntoIter` into a `Vec` again. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-19-dakr@kernel.org [ Added newline in documentation, changed case of section to be consistent with an existing one, fixed typo. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: alloc: implement `IntoIterator` for `Vec`Danilo Krummrich
Implement `IntoIterator` for `Vec`, `Vec`'s `IntoIter` type, as well as `Iterator` for `IntoIter`. `Vec::into_iter` disassembles the `Vec` into its raw parts; additionally, `IntoIter` keeps track of a separate pointer, which is incremented correspondingly as the iterator advances, while the length, or the count of elements, is decremented. This also means that `IntoIter` takes the ownership of the backing buffer and is responsible to drop the remaining elements and free the backing buffer, if it's dropped. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-18-dakr@kernel.org [ Fixed typos. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: alloc: implement kernel `Vec` typeDanilo Krummrich
`Vec` provides a contiguous growable array type with contents allocated with the kernel's allocators (e.g. `Kmalloc`, `Vmalloc` or `KVmalloc`). In contrast to Rust's stdlib `Vec` type, the kernel `Vec` type considers the kernel's GFP flags for all appropriate functions, always reports allocation failures through `Result<_, AllocError>` and remains independent from unstable features. [ This patch starts using a new unstable feature, `inline_const`, but it was stabilized in Rust 1.79.0, i.e. the next version after the minimum one, thus it will not be an issue. - Miguel ] Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-17-dakr@kernel.org [ Cleaned `rustdoc` unescaped backtick warning, added a couple more backticks elsewhere, fixed typos, sorted `feature`s, rewrapped documentation lines. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: alloc: introduce `ArrayLayout`Benno Lossin
When allocating memory for arrays using allocators, the `Layout::array` function is typically used. It returns a result, since the given size might be too big. However, `Vec` and its iterators store their allocated capacity and thus they already did check that the size is not too big. The `ArrayLayout` type provides this exact behavior, as it can be infallibly converted into a `Layout`. Instead of a `usize` capacity, `Vec` and other similar array-storing types can use `ArrayLayout` instead. Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Benno Lossin <benno.lossin@proton.me> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-16-dakr@kernel.org [ Formatted a few comments. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: alloc: add `Box` to preludeDanilo Krummrich
Now that we removed `BoxExt` and the corresponding includes in prelude.rs, add the new kernel `Box` type instead. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-15-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: alloc: remove extension of std's `Box`Danilo Krummrich
Now that all existing `Box` users were moved to the kernel `Box` type, remove the `BoxExt` extension and all other related extensions. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-14-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: treewide: switch to our kernel `Box` typeDanilo Krummrich
Now that we got the kernel `Box` type in place, convert all existing `Box` users to make use of it. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-13-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: alloc: implement kernel `Box`Danilo Krummrich
`Box` provides the simplest way to allocate memory for a generic type with one of the kernel's allocators, e.g. `Kmalloc`, `Vmalloc` or `KVmalloc`. In contrast to Rust's `Box` type, the kernel `Box` type considers the kernel's GFP flags for all appropriate functions, always reports allocation failures through `Result<_, AllocError>` and remains independent from unstable features. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-12-dakr@kernel.org [ Added backticks, fixed typos. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: alloc: add __GFP_NOWARN to `Flags`Danilo Krummrich
Some test cases in subsequent patches provoke allocation failures. Add `__GFP_NOWARN` to enable test cases to silence unpleasant warnings. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-11-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: alloc: implement `KVmalloc` allocatorDanilo Krummrich
Implement `Allocator` for `KVmalloc`, an `Allocator` that tries to allocate memory with `kmalloc` first and, on failure, falls back to `vmalloc`. All memory allocations made with `KVmalloc` end up in `kvrealloc_noprof()`; all frees in `kvfree()`. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-10-dakr@kernel.org [ Reworded typo. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: alloc: implement `Vmalloc` allocatorDanilo Krummrich
Implement `Allocator` for `Vmalloc`, the kernel's virtually contiguous allocator, typically used for larger objects, (much) larger than page size. All memory allocations made with `Vmalloc` end up in `vrealloc()`. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-9-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: alloc: add module `allocator_test`Danilo Krummrich
`Allocator`s, such as `Kmalloc`, will be used by e.g. `Box` and `Vec` in subsequent patches, and hence this dependency propagates throughout the whole kernel. Add the `allocator_test` module that provides an empty implementation for all `Allocator`s in the kernel, such that we don't break the `rusttest` make target in subsequent patches. Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-8-dakr@kernel.org [ Added missing `_old_layout` parameter as discussed. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-10-15rust: alloc: implement `Allocator` for `Kmalloc`Danilo Krummrich
Implement `Allocator` for `Kmalloc`, the kernel's default allocator, typically used for objects smaller than page size. All memory allocations made with `Kmalloc` end up in `krealloc()`. It serves as allocator for the subsequently introduced types `KBox` and `KVec`. Reviewed-by: Benno Lossin <benno.lossin@proton.me> Reviewed-by: Gary Guo <gary@garyguo.net> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241004154149.93856-7-dakr@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>