Miguel Ojeda [Sun, 17 Nov 2024 13:31:27 +0000 (14:31 +0100)]
docs: rust: remove spurious item in `expect` list
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.
Miguel Ojeda [Sat, 16 Nov 2024 18:15:37 +0000 (19:15 +0100)]
rust: allow `clippy::needless_lifetimes`
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.
Miguel Ojeda [Mon, 11 Nov 2024 20:16:07 +0000 (21:16 +0100)]
rust: warn on bindgen < 0.69.5 and libclang >= 19.1
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].
Gary Guo [Fri, 13 Sep 2024 21:29:23 +0000 (22:29 +0100)]
rust: use custom FFI integer types
Currently FFI integer types are defined in libcore. This commit creates
the `ffi` crate and asks bindgen to use that crate for FFI integer types
instead of `core::ffi`.
This commit is preparatory and no type changes are made in this commit
yet.
Signed-off-by: Gary Guo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
[ Added `rustdoc`, `rusttest` and KUnit tests support. Rebased on top of
`rust-next` (e.g. migrated more `core::ffi` cases). Reworded crate
docs slightly and formatted. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>
Gary Guo [Fri, 13 Sep 2024 21:29:22 +0000 (22:29 +0100)]
rust: map `__kernel_size_t` and friends also to usize/isize
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.
Gary Guo [Fri, 13 Sep 2024 21:29:21 +0000 (22:29 +0100)]
rust: fix size_t in bindgen prototypes of C builtins
Without `-fno-builtin`, for functions like memcpy/memmove (and many
others), bindgen seems to be using the clang-provided prototype. This
prototype is ABI-wise compatible, but the issue is that it does not have
the same information as the source code w.r.t. typedefs.
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 ]
Alice Ryhl [Wed, 23 Oct 2024 13:23:18 +0000 (13:23 +0000)]
rust: sync: add global lock support
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.
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.
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.
Previously, the rusttest target for the macros crate did not specify
the dependencies necessary to run the rustdoc tests. These tests rely on
the kernel crate, so add the dependencies.
Signed-off-by: Ethan D. Twardy <[email protected]> Link: https://github.com/Rust-for-Linux/linux/issues/1076 Link: https://lore.kernel.org/r/[email protected]
[ Rebased (`alloc` is gone nowadays, sysroot handling is simpler) and
simplified (reused `rustdoc_test` rule instead of adding a new one,
no need for `rustdoc-compiler_builtins`, removed unneeded `macros`
explicit path). Made `vtable` example fail (avoiding to increase
the complexity in the `rusttest` target). Removed unstable
`-Zproc-macro-backtrace` option. Reworded accordingly. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>
Dirk Behme [Wed, 2 Oct 2024 05:03:01 +0000 (07:03 +0200)]
rust: types: extend `Opaque` documentation
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].
Francesco Zardi [Tue, 3 Sep 2024 17:30:29 +0000 (19:30 +0200)]
rust: block: fix formatting of `kernel::block::mq::request` module
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 <[email protected]> Closes: https://github.com/Rust-for-Linux/linux/issues/1108 Signed-off-by: Francesco Zardi <[email protected]> Acked-by: Andreas Hindborg <[email protected]> Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module") Link: https://lore.kernel.org/r/[email protected]
[ Added an extra intra-doc link. Took the chance to add some periods
for consistency. Reworded slightly. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>
Yutaro Ohno [Mon, 21 Oct 2024 02:58:47 +0000 (11:58 +0900)]
rust: kernel: fix THIS_MODULE header path in ThisModule doc comment
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`.
Alice Ryhl [Wed, 16 Oct 2024 11:34:25 +0000 (11:34 +0000)]
rust: page: add Rust version of PAGE_ALIGN
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`").
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.
Thomas Böhler [Sat, 19 Oct 2024 08:22:51 +0000 (10:22 +0200)]
drm/panic: allow verbose boolean for clarity
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.
Thomas Böhler [Sat, 19 Oct 2024 08:22:50 +0000 (10:22 +0200)]
drm/panic: correctly indent continuation of line in list item
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.
Thomas Böhler [Sat, 19 Oct 2024 08:22:49 +0000 (10:22 +0200)]
drm/panic: remove redundant field when assigning value
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.
Thomas Böhler [Sat, 19 Oct 2024 08:22:48 +0000 (10:22 +0200)]
drm/panic: prefer eliding lifetimes
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.
Thomas Böhler [Sat, 19 Oct 2024 08:22:47 +0000 (10:22 +0200)]
drm/panic: remove unnecessary borrow in alignment_pattern
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)]`
Thomas Böhler [Sat, 19 Oct 2024 08:22:46 +0000 (10:22 +0200)]
drm/panic: avoid reimplementing Iterator::find
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)]`
MAINTAINERS: add entry for the Rust `alloc` module
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`.
kbuild: rust: remove the `alloc` crate and `GlobalAlloc`
Now that we have our own `Allocator`, `Box` and `Vec` types we can remove
Rust's `alloc` crate and the `new_uninit` unstable feature.
Also remove `Kmalloc`'s `GlobalAlloc` implementation -- we can't remove
this in a separate patch, since the `alloc` crate requires a
`#[global_allocator]` to set, that implements `GlobalAlloc`.
rust: alloc: implement `Cmalloc` in module allocator_test
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.
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.
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.
`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 ]
Benno Lossin [Fri, 4 Oct 2024 15:41:19 +0000 (17:41 +0200)]
rust: alloc: introduce `ArrayLayout`
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.
`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.
`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.
`ReallocFunc` is an abstraction for the kernel's realloc derivates, such
as `krealloc`, `vrealloc` and `kvrealloc`.
All of the named functions share the same function signature and
implement the same semantics. The `ReallocFunc` abstractions provides a
generalized wrapper around those, to trivialize the implementation of
`Kmalloc`, `Vmalloc` and `KVmalloc` in subsequent patches.
Reviewed-by: Benno Lossin <[email protected]> Reviewed-by: Gary Guo <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://lore.kernel.org/r/[email protected]
[ Added temporary `allow(dead_code)` for `dangling_from_layout` to clean
warning in `rusttest` target as discussed in the list (but it is
needed earlier, i.e. in this patch already). Added colon. - Miguel ] Signed-off-by: Miguel Ojeda <[email protected]>
Filipe Xavier [Sat, 5 Oct 2024 19:51:23 +0000 (19:51 +0000)]
rust: error: optimize error type to use nonzero
Optimize `Result<(), Error>` size by changing `Error` type to
`NonZero*` for niche optimization.
This reduces the space used by the `Result` type, as the `NonZero*`
type enables the compiler to apply more efficient memory layout.
For example, the `Result<(), Error>` changes size from 8 to 4 bytes.
Deepak Thukral [Fri, 4 Oct 2024 12:56:16 +0000 (14:56 +0200)]
rust: std_vendor: update dbg macro from Rust upstream
`dbg!` contains adapted code from Rust upstream. Compare the kernel
code with the Rust upstream one and update missing column numbers in
`dbg!` outputs.
Column numbers are not copied but adjusted for the kernel's examples.
Gary Guo [Sun, 15 Sep 2024 13:26:31 +0000 (14:26 +0100)]
rust: enable arbitrary_self_types and remove `Receiver`
The term "receiver" means that a type can be used as the type of `self`,
and thus enables method call syntax `foo.bar()` instead of
`Foo::bar(foo)`. Stable Rust as of today (1.81) enables a limited
selection of types (primitives and types in std, e.g. `Box` and `Arc`)
to be used as receivers, while custom types cannot.
We want the kernel `Arc` type to have the same functionality as the Rust
std `Arc`, so we use the `Receiver` trait (gated behind `receiver_trait`
unstable feature) to gain the functionality.
The `arbitrary_self_types` RFC [1] (tracking issue [2]) is accepted and
it will allow all types that implement a new `Receiver` trait (different
from today's unstable trait) to be used as receivers. This trait will be
automatically implemented for all `Deref` types, which include our `Arc`
type, so we no longer have to opt-in to be used as receiver. To prepare
us for the change, remove the `Receiver` implementation and the
associated feature. To still allow `Arc` and others to be used as method
receivers, turn on `arbitrary_self_types` feature instead.
This feature gate is introduced in 1.23.0. It used to enable both
`Deref` types and raw pointer types to be used as receivers, but the
latter is now split into a different feature gate in Rust 1.83 nightly.
We do not need receivers on raw pointers so this change would not affect
us and usage of `arbitrary_self_types` feature would work for all Rust
versions that we support (>=1.78).
Miguel Ojeda [Wed, 4 Sep 2024 20:43:46 +0000 (22:43 +0200)]
Documentation: rust: discuss `#[expect(...)]` in the guidelines
Discuss `#[expect(...)]` in the Lints sections of the coding guidelines
document, which is an upcoming feature in Rust 1.81.0, and explain that
it is generally to be preferred over `allow` unless there is a reason
not to use it (e.g. conditional compilation being involved).
Miguel Ojeda [Wed, 4 Sep 2024 20:43:45 +0000 (22:43 +0200)]
rust: start using the `#[expect(...)]` attribute
In Rust, it is possible to `allow` particular warnings (diagnostics,
lints) locally, making the compiler ignore instances of a given warning
within a given function, module, block, etc.
It is similar to `#pragma GCC diagnostic push` + `ignored` + `pop` in C:
By that virtue, it makes it possible to comfortably enable more
diagnostics by default (i.e. outside `W=` levels) that may have some
false positives but that are otherwise quite useful to keep enabled to
catch potential mistakes.
The `#[expect(...)]` attribute [1] takes this further, and makes the
compiler warn if the diagnostic was _not_ produced. For instance, the
following will ensure that, when `f()` is called somewhere, we will have
to remove the attribute:
#[expect(dead_code)]
fn f() {}
If we do not, we get a warning from the compiler:
warning: this lint expectation is unfulfilled
--> x.rs:3:10
|
3 | #[expect(dead_code)]
| ^^^^^^^^^
|
= note: `#[warn(unfulfilled_lint_expectations)]` on by default
This means that `expect`s do not get forgotten when they are not needed.
See the next commit for more details, nuances on its usage and
documentation on the feature.
The attribute requires the `lint_reasons` [2] unstable feature, but it
is becoming stable in 1.81.0 (to be released on 2024-09-05) and it has
already been useful to clean things up in this patch series, finding
cases where the `allow`s should not have been there.
Thus, enable `lint_reasons` and convert some of our `allow`s to `expect`s
where possible.
This feature was also an example of the ongoing collaboration between
Rust and the kernel -- we tested it in the kernel early on and found an
issue that was quickly resolved [3].
Miguel Ojeda [Wed, 4 Sep 2024 20:43:44 +0000 (22:43 +0200)]
Documentation: rust: add coding guidelines on lints
In the C side, disabling diagnostics locally, i.e. within the source code,
is rare (at least in the kernel). Sometimes warnings are manipulated
via the flags at the translation unit level, but that is about it.
In Rust, it is easier to change locally the "level" of lints
(e.g. allowing them locally). In turn, this means it is easier to
globally enable more lints that may trigger a few false positives here
and there that need to be allowed locally, but that generally can spot
issues or bugs.
Miguel Ojeda [Wed, 4 Sep 2024 20:43:43 +0000 (22:43 +0200)]
rust: enable Clippy's `check-private-items`
In Rust 1.76.0, Clippy added the `check-private-items` lint configuration
option. When turned on (the default is off), it makes several lints
check private items as well.
In our case, it affects two lints we have enabled [1]:
`missing_safety_doc` and `unnecessary_safety_doc`.
It also seems to affect the new `too_long_first_doc_paragraph` lint [2],
even though the documentation does not mention it.
Thus allow the few instances remaining we currently hit and enable
the lint.
Miguel Ojeda [Wed, 4 Sep 2024 20:43:42 +0000 (22:43 +0200)]
rust: provide proper code documentation titles
Rust 1.82.0's Clippy is introducing [1][2] a new warn-by-default lint,
`too_long_first_doc_paragraph` [3], which is intended to catch titles
of code documentation items that are too long (likely because no title
was provided and the item documentation starts with a paragraph).
This lint does not currently trigger anywhere, but it does detect a couple
cases if checking for private items gets enabled (which we will do in
the next commit):
error: first doc comment paragraph is too long
--> rust/kernel/init/__internal.rs:18:1
|
18 | / /// This is the module-internal type implementing `PinInit` and `Init`. It is unsafe to create this
19 | | /// type, since the closure needs to fulfill the same safety requirement as the
20 | | /// `__pinned_init`/`__init` functions.
| |_
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#too_long_first_doc_paragraph
= note: `-D clippy::too-long-first-doc-paragraph` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::too_long_first_doc_paragraph)]`
error: first doc comment paragraph is too long
--> rust/kernel/sync/arc/std_vendor.rs:3:1
|
3 | / //! The contents of this file come from the Rust standard library, hosted in
4 | | //! the <https://github.com/rust-lang/rust> repository, licensed under
5 | | //! "Apache-2.0 OR MIT" and adapted for kernel use. For copyright details,
6 | | //! see <https://github.com/rust-lang/rust/blob/master/COPYRIGHT>.
| |_
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#too_long_first_doc_paragraph
Thus clean those two instances.
In addition, since we have a second `std_vendor.rs` file with a similar
header, do the same there too (even if that one does not trigger the lint,
because it is `doc(hidden)`).
Miguel Ojeda [Wed, 4 Sep 2024 20:43:41 +0000 (22:43 +0200)]
rust: rbtree: fix `SAFETY` comments that should be `# Safety` sections
The tag `SAFETY` is used for safety comments, i.e. `// SAFETY`, while a
`Safety` section is used for safety preconditions in code documentation,
i.e. `/// # Safety`.
Fix the three instances recently added in `rbtree` that Clippy would
have normally caught in a public item, so that we can enable checking
of private items in one of the following commits.
Miguel Ojeda [Wed, 4 Sep 2024 20:43:40 +0000 (22:43 +0200)]
rust: replace `clippy::dbg_macro` with `disallowed_macros`
Back when we used Rust 1.60.0 (before Rust was merged in the kernel),
we added `-Wclippy::dbg_macro` to the compilation flags. This worked
great with our custom `dbg!` macro (vendored from `std`, but slightly
modified to use the kernel printing facilities).
However, in the very next version, 1.61.0, it stopped working [1] since
the lint started to use a Rust diagnostic item rather than a path to find
the `dbg!` macro [1]. This behavior remains until the current nightly
(1.83.0).
Therefore, currently, the `dbg_macro` is not doing anything, which
explains why we can invoke `dbg!` in samples/rust/rust_print.rs`, as well
as why changing the `#[allow()]`s to `#[expect()]`s in `std_vendor.rs`
doctests does not work since they are not fulfilled.
One possible workaround is using `rustc_attrs` like the standard library
does. However, this is intended to be internal, and we just started
supporting several Rust compiler versions, so it is best to avoid it.
Therefore, instead, use `disallowed_macros`. It is a stable lint and
is more flexible (in that we can provide different macros), although
its diagnostic message(s) are not as nice as the specialized one (yet),
and does not allow to set different lint levels per macro/path [2].
In turn, this requires allowing the (intentional) `dbg!` use in the
sample, as one would have expected.
Finally, in a single case, the `allow` is fixed to be an inner attribute,
since otherwise it was not being applied.
Miguel Ojeda [Wed, 4 Sep 2024 20:43:39 +0000 (22:43 +0200)]
rust: introduce `.clippy.toml`
Some Clippy lints can be configured/tweaked. We will use these knobs to
our advantage in later commits.
This is done via a configuration file, `.clippy.toml` [1]. The file is
currently unstable. This may be a problem in the future, but we can adapt
as needed. In addition, we proposed adding Clippy to the Rust CI's RFL
job [2], so we should be able to catch issues pre-merge.
Rust 1.58.0 (before Rust was merged into the kernel) made Clippy's
`non_send_fields_in_send_ty` lint part of the `suspicious` lint group for
a brief window of time [1] until the minor version 1.58.1 got released
a week after, where the lint was moved back to `nursery`.
By that time, we had already upgraded to that Rust version, and thus we
had `allow`ed the lint here for `CondVar`.
Nowadays, Clippy's `non_send_fields_in_send_ty` would still trigger here
if it were enabled.
Moreover, if enabled, `Lock<T, B>` and `Task` would also require an
`allow`. Therefore, it does not seem like someone is actually enabling it
(in, e.g., a custom flags build).
Finally, the lint does not appear to have had major improvements since
then [2].
Miguel Ojeda [Wed, 4 Sep 2024 20:43:36 +0000 (22:43 +0200)]
rust: enable `rustdoc::unescaped_backticks` lint
In Rust 1.71.0, `rustdoc` added the `unescaped_backticks` lint, which
detects what are typically typos in Markdown formatting regarding inline
code [1], e.g. from the Rust standard library:
/// ... to `deref`/`deref_mut`` must ...
/// ... use [`from_mut`]`. Specifically, ...
It does not seem to have almost any false positives, from the experience
of enabling it in the Rust standard library [2], which will be checked
starting with Rust 1.82.0. The maintainers also confirmed it is ready
to be used.
Miguel Ojeda [Wed, 4 Sep 2024 20:43:35 +0000 (22:43 +0200)]
rust: enable `clippy::ignored_unit_patterns` lint
In Rust 1.73.0, Clippy introduced the `ignored_unit_patterns` lint [1]:
> Matching with `()` explicitly instead of `_` outlines the fact that
> the pattern contains no data. Also it would detect a type change
> that `_` would ignore.
There is only a single case that requires a change:
error: matching over `()` is more explicit
--> rust/kernel/types.rs:176:45
|
176 | ScopeGuard::new_with_data((), move |_| cleanup())
| ^ help: use `()` instead of `_`: `()`
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#ignored_unit_patterns
= note: requested on the command line with `-D clippy::ignored-unit-patterns`
Thus clean it up and enable the lint -- no functional change intended.
In Rust 1.67.0, Clippy added the `unnecessary_safety_doc` lint [1],
which is similar to `unnecessary_safety_comment`, but for `# Safety`
sections, i.e. safety preconditions in the documentation.
This is something that should not happen with our coding guidelines in
mind. Thus enable the lint to have it machine-checked.
In Rust 1.67.0, Clippy added the `unnecessary_safety_comment` lint [1],
which is the "inverse" of `undocumented_unsafe_blocks`: it finds places
where safe code has a `// SAFETY` comment attached.
The lint currently finds 3 places where we had such mistakes, thus it
seems already quite useful.
Checking that we are not missing any `// SAFETY` comments in our `unsafe`
blocks is something we have wanted to do for a long time, as well as
cleaning up the remaining cases that were not documented [1].
Back when Rust for Linux started, this was something that could have
been done via a script, like Rust's `tidy`. Soon after, in Rust 1.58.0,
Clippy implemented the `undocumented_unsafe_blocks` lint [2].
Even though the lint has a few false positives, e.g. in some cases where
attributes appear between the comment and the `unsafe` block [3], there
are workarounds and the lint seems quite usable already.
Thus enable the lint now.
We still have a few cases to clean up, so just allow those for the moment
by writing a `TODO` comment -- some of those may be good candidates for
new contributors.
Miguel Ojeda [Wed, 4 Sep 2024 20:43:31 +0000 (22:43 +0200)]
rust: types: avoid repetition in `{As,From}Bytes` impls
In order to provide `// SAFETY` comments for every `unsafe impl`, we would
need to repeat them, which is not very useful and would be harder to read.
We could perhaps allow the lint (ideally within a small module), but we
can take the chance to avoid the repetition of the `impl`s themselves
too by using a small local macro, like in other places where we have
had to do this sort of thing.
Thus add the straightforward `impl_{from,as}bytes!` macros and use them
to implement `FromBytes`.
This, in turn, will allow us in the next patch to place a `// SAFETY`
comment that defers to the actual invocation of the macro.
Perform the same clean commit b2516f7af9d2 ("rust: kernel: remove
`#[allow(clippy::new_ret_no_self)]`") did for a case that appeared in
workqueue in parallel in commit 7324b88975c5 ("rust: workqueue: add
helper for defining work_struct fields"):
Clippy triggered a false positive on its `new_ret_no_self` lint
when using the `pin_init!` macro. Since Rust 1.67.0, that does
not happen anymore, since Clippy learnt to not warn about
`-> impl Trait<Self>` [1][2].
The kernel nowadays uses Rust 1.72.1, thus remove the `#[allow]`.
Miguel Ojeda [Wed, 25 Sep 2024 14:06:00 +0000 (16:06 +0200)]
docs: rust: quick-start: add Ubuntu
Ubuntu has changed their maintenance model for Rust toolchains and is
now providing recent Rust releases in their releases, including both
LTS and non-LTS (interim) releases.
Therefore, add instructions to the Quick Start guide for Ubuntu, like
it is done for the other distributions.
Linus Torvalds [Sun, 6 Oct 2024 18:34:55 +0000 (11:34 -0700)]
Merge tag 'kbuild-fixes-v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild fixes from Masahiro Yamada:
- Move non-boot built-in DTBs to the .rodata section
- Fix Kconfig bugs
- Fix maint scripts in the linux-image Debian package
- Import some list macros to scripts/include/
* tag 'kbuild-fixes-v6.12' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
kbuild: deb-pkg: Remove blank first line from maint scripts
kbuild: fix a typo dt_binding_schema -> dt_binding_schemas
scripts: import more list macros
kconfig: qconf: fix buffer overflow in debug links
kconfig: qconf: move conf_read() before drawing tree pain
kconfig: clear expr::val_is_valid when allocated
kconfig: fix infinite loop in sym_calc_choice()
kbuild: move non-boot built-in DTBs to .rodata section
Linus Torvalds [Sun, 6 Oct 2024 18:11:01 +0000 (11:11 -0700)]
Merge tag 'platform-drivers-x86-v6.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform driver fixes from Hans de Goede:
- Intel PMC fix for suspend/resume issues on some Sky and Kaby Lake
laptops
- Intel Diamond Rapids hw-id additions
- Documentation and MAINTAINERS fixes
- Some other small fixes
* tag 'platform-drivers-x86-v6.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors
platform/x86: wmi: Update WMI driver API documentation
platform/x86: dell-ddv: Fix typo in documentation
platform/x86: dell-sysman: add support for alienware products
platform/x86/intel: power-domains: Add Diamond Rapids support
platform/x86: ISST: Add Diamond Rapids to support list
platform/x86:intel/pmc: Disable ACPI PM Timer disabling on Sky and Kaby Lake
platform/x86: dell-laptop: Do not fail when encountering unsupported batteries
MAINTAINERS: Update Intel In Field Scan(IFS) entry
platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug
Linus Torvalds [Sun, 6 Oct 2024 17:53:28 +0000 (10:53 -0700)]
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
"ARM64:
- Fix pKVM error path on init, making sure we do not change critical
system registers as we're about to fail
- Make sure that the host's vector length is at capped by a value
common to all CPUs
- Fix kvm_has_feat*() handling of "negative" features, as the current
code is pretty broken
- Promote Joey to the status of official reviewer, while James steps
down -- hopefully only temporarly
x86:
- Fix compilation with KVM_INTEL=KVM_AMD=n
- Fix disabling KVM_X86_QUIRK_SLOT_ZAP_ALL when shadow MMU is in use
Selftests:
- Fix compilation on non-x86 architectures"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
x86/reboot: emergency callbacks are now registered by common KVM code
KVM: x86: leave kvm.ko out of the build if no vendor module is requested
KVM: x86/mmu: fix KVM_X86_QUIRK_SLOT_ZAP_ALL for shadow MMU
KVM: arm64: Fix kvm_has_feat*() handling of negative features
KVM: selftests: Fix build on architectures other than x86_64
KVM: arm64: Another reviewer reshuffle
KVM: arm64: Constrain the host to the maximum shared SVE VL with pKVM
KVM: arm64: Fix __pkvm_init_vcpu cptr_el2 error path
Aaron Thompson [Fri, 4 Oct 2024 07:52:45 +0000 (07:52 +0000)]
kbuild: deb-pkg: Remove blank first line from maint scripts
The blank line causes execve() to fail:
# strace ./postinst
execve("./postinst", ...) = -1 ENOEXEC (Exec format error)
strace: exec: Exec format error
+++ exited with 1 +++
However running the scripts via shell does work (at least with bash)
because the shell attempts to execute the file as a shell script when
execve() fails.
Fixes: b611daae5efc ("kbuild: deb-pkg: split image and debug objects staging out into functions") Signed-off-by: Aaron Thompson <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-by: Nicolas Schier <[email protected]> Signed-off-by: Masahiro Yamada <[email protected]>
Hans de Goede [Sat, 5 Oct 2024 13:05:45 +0000 (15:05 +0200)]
platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors
x86_android_tablet_remove() frees the pdevs[] array, so it should not
be used after calling x86_android_tablet_remove().
When platform_device_register() fails, store the pdevs[x] PTR_ERR() value
into the local ret variable before calling x86_android_tablet_remove()
to avoid using pdevs[] after it has been freed.
Fixes: 5eba0141206e ("platform/x86: x86-android-tablets: Add support for instantiating platform-devs") Fixes: e2200d3f26da ("platform/x86: x86-android-tablets: Add gpio_keys support to x86_android_tablet_init()") Cc: [email protected] Reported-by: Aleksandr Burakov <[email protected]> Closes: https://lore.kernel.org/platform-driver-x86/[email protected]/ Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Hans de Goede [Thu, 3 Oct 2024 20:26:13 +0000 (22:26 +0200)]
platform/x86:intel/pmc: Disable ACPI PM Timer disabling on Sky and Kaby Lake
There have been multiple reports that the ACPI PM Timer disabling is
causing Sky and Kaby Lake systems to hang on all suspend (s2idle, s3,
hibernate) methods.
Remove the acpi_pm_tmr_ctl_offset and acpi_pm_tmr_disable_bit settings from
spt_reg_map to disable the ACPI PM Timer disabling on Sky and Kaby Lake to
fix the hang on suspend.
Armin Wolf [Tue, 1 Oct 2024 21:28:35 +0000 (23:28 +0200)]
platform/x86: dell-laptop: Do not fail when encountering unsupported batteries
If the battery hook encounters a unsupported battery, it will
return an error. This in turn will cause the battery driver to
automatically unregister the battery hook.
On machines with multiple batteries however, this will prevent
the battery hook from handling the primary battery, since it will
always get unregistered upon encountering one of the unsupported
batteries.
Fix this by simply ignoring unsupported batteries.
Jithu Joseph [Tue, 1 Oct 2024 17:08:08 +0000 (10:08 -0700)]
MAINTAINERS: Update Intel In Field Scan(IFS) entry
Ashok is no longer with Intel and his e-mail address will start bouncing
soon. Update his email address to the new one he provided to ensure
correct contact details in the MAINTAINERS file.
projects / linux.git / log