user/sven/linux.git/rust, branch v6.6.17

rust: upgrade to Rust 1.73.0

2024-02-16T18:10:43Z

commit e08ff622c91af997cb89bc47e90a1a383e938bd0 upstream. This is the next upgrade to the Rust toolchain, from 1.72.1 to 1.73.0 (i.e. the latest) [1]. See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4da06e ("rust: upgrade to Rust 1.68.2"). # Unstable features No unstable features (that we use) were stabilized. Therefore, the only unstable feature allowed to be used outside the `kernel` crate is still `new_uninit`, though other code to be upstreamed may increase the list. Please see [3] for details. # Required changes For the upgrade, the following changes are required: - Allow `internal_features` for `feature(compiler_builtins)` since now Rust warns about using internal compiler and standard library features (similar to how it also warns about incomplete ones) [4]. - A cleanup for a documentation link thanks to a new `rustdoc` lint. See previous commits for details. - A need to make an intra-doc link to a macro explicit, due to a change in behavior in `rustdoc`. See previous commits for details. # `alloc` upgrade and reviewing The vast majority of changes are due to our `alloc` fork being upgraded at once. There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream. Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream `alloc` and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream. Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions. To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of `alloc` we use) before and after applying this patch: # Get the difference with respect to the old version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > old.patch git -C linux restore rust/alloc # Apply this patch. git -C linux am rust-upgrade.patch # Get the difference with respect to the new version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > new.patch git -C linux restore rust/alloc Now one may check the `new.patch` to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended. Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1730-2023-10-05 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: https://github.com/Rust-for-Linux/linux/issues/2 [3] Link: https://github.com/rust-lang/compiler-team/issues/596 [4] Reviewed-by: Martin Rodriguez Reboredo Reviewed-by: Vincenzo Palazzo Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20231005210556.466856-4-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

rust: print: use explicit link in documentation

2024-02-16T18:10:43Z

commit a53d8cdd5a0aec75ae32badc2d8995c59ea6e3f0 upstream. The future `rustdoc` in the Rust 1.73.0 upgrade requires an explicit link for `pr_info!`: error: unresolved link to `pr_info` --> rust/kernel/print.rs:395:63 | 395 | /// Use only when continuing a previous `pr_*!` macro (e.g. [`pr_info!`]). | ^^^^^^^^ no item named `pr_info` in scope | = note: `macro_rules` named `pr_info` exists in this crate, but it is not in scope at this link's location = note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings` Thus do so to avoid a broken link while upgrading. Reviewed-by: Alice Ryhl Reviewed-by: Vincenzo Palazzo Reviewed-by: Finn Behrens Reviewed-by: Martin Rodriguez Reboredo Link: https://lore.kernel.org/r/20231005210556.466856-3-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

rust: task: remove redundant explicit link

2024-02-16T18:10:43Z

commit c61bcc278b1924da13fd52edbd46b08a518c11ef upstream. Starting with Rust 1.73.0, `rustdoc` detects redundant explicit links with its new lint `redundant_explicit_links` [1]: error: redundant explicit link target --> rust/kernel/task.rs:85:21 | 85 | /// [`current`](crate::current) macro because it is safe. | --------- ^^^^^^^^^^^^^^ explicit target is redundant | | | because label contains path that resolves to same destination | = note: when a link's destination is not specified, the label is used to resolve intra-doc links = note: `-D rustdoc::redundant-explicit-links` implied by `-D warnings` help: remove explicit link target | 85 | /// [`current`] macro because it is safe. In order to avoid the warning in the compiler upgrade commit, make it an intra-doc link as the tool suggests. Link: https://github.com/rust-lang/rust/pull/113167 [1] Reviewed-by: Finn Behrens Reviewed-by: Alice Ryhl Reviewed-by: Martin Rodriguez Reboredo Reviewed-by: Vincenzo Palazzo Link: https://lore.kernel.org/r/20231005210556.466856-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

rust: upgrade to Rust 1.72.1

2024-02-16T18:10:43Z

commit ae6df65dabc3f8bd89663d96203963323e266d90 upstream. This is the third upgrade to the Rust toolchain, from 1.71.1 to 1.72.1 (i.e. the latest) [1]. See the upgrade policy [2] and the comments on the first upgrade in commit 3ed03f4da06e ("rust: upgrade to Rust 1.68.2"). # Unstable features No unstable features (that we use) were stabilized. Therefore, the only unstable feature allowed to be used outside the `kernel` crate is still `new_uninit`, though other code to be upstreamed may increase the list. Please see [3] for details. # Other improvements Previously, the compiler could incorrectly generate a `.eh_frame` section under `-Cpanic=abort`. We were hitting this bug when debug assertions were enabled (`CONFIG_RUST_DEBUG_ASSERTIONS=y`) [4]: LD .tmp_vmlinux.kallsyms1 ld.lld: error: :(.eh_frame) is being placed in '.eh_frame' Gary fixed the issue in Rust 1.72.0 [5]. # Required changes For the upgrade, the following changes are required: - A call to `Box::from_raw` in `rust/kernel/sync/arc.rs` now requires an explicit `drop()` call. See previous patch for details. # `alloc` upgrade and reviewing The vast majority of changes are due to our `alloc` fork being upgraded at once. There are two kinds of changes to be aware of: the ones coming from upstream, which we should follow as closely as possible, and the updates needed in our added fallible APIs to keep them matching the newer infallible APIs coming from upstream. Instead of taking a look at the diff of this patch, an alternative approach is reviewing a diff of the changes between upstream `alloc` and the kernel's. This allows to easily inspect the kernel additions only, especially to check if the fallible methods we already have still match the infallible ones in the new version coming from upstream. Another approach is reviewing the changes introduced in the additions in the kernel fork between the two versions. This is useful to spot potentially unintended changes to our additions. To apply these approaches, one may follow steps similar to the following to generate a pair of patches that show the differences between upstream Rust and the kernel (for the subset of `alloc` we use) before and after applying this patch: # Get the difference with respect to the old version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > old.patch git -C linux restore rust/alloc # Apply this patch. git -C linux am rust-upgrade.patch # Get the difference with respect to the new version. git -C rust checkout $(linux/scripts/min-tool-version.sh rustc) git -C linux ls-tree -r --name-only HEAD -- rust/alloc | cut -d/ -f3- | grep -Fv README.md | xargs -IPATH cp rust/library/alloc/src/PATH linux/rust/alloc/PATH git -C linux diff --patch-with-stat --summary -R > new.patch git -C linux restore rust/alloc Now one may check the `new.patch` to take a look at the additions (first approach) or at the difference between those two patches (second approach). For the latter, a side-by-side tool is recommended. Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1721-2023-09-19 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: https://github.com/Rust-for-Linux/linux/issues/2 [3] Closes: https://github.com/Rust-for-Linux/linux/issues/1012 [4] Link: https://github.com/rust-lang/rust/pull/112403 [5] Reviewed-by: Martin Rodriguez Reboredo Reviewed-by: Gary Guo Reviewed-by: Alice Ryhl Reviewed-by: Björn Roy Baron Link: https://lore.kernel.org/r/20230823160244.188033-3-ojeda@kernel.org [ Used 1.72.1 instead of .0 (no changes in `alloc`) and reworded to mention that we hit the `.eh_frame` bug under debug assertions. ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

rust: arc: add explicit `drop()` around `Box::from_raw()`

2024-02-16T18:10:43Z

commit 828176d037e29f813792a8b3ac1591834240e96f upstream. `Box::from_raw()` is `#[must_use]`, which means the result cannot go unused. In Rust 1.71.0, this was not detected because the block expression swallows the diagnostic [1]: unsafe { Box::from_raw(self.ptr.as_ptr()) }; It would have been detected, however, if the line had been instead: unsafe { Box::from_raw(self.ptr.as_ptr()); } i.e. the semicolon being inside the `unsafe` block, rather than outside. In Rust 1.72.0, the compiler started warning about this [2], so without this patch we will get: error: unused return value of `alloc::boxed::Box::::from_raw` that must be used --> rust/kernel/sync/arc.rs:302:22 | 302 | unsafe { Box::from_raw(self.ptr.as_ptr()) }; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: call `drop(Box::from_raw(ptr))` if you intend to drop the `Box` = note: `-D unused-must-use` implied by `-D warnings` help: use `let _ = ...` to ignore the resulting value | 302 | unsafe { let _ = Box::from_raw(self.ptr.as_ptr()); }; | +++++++ + Thus add an add an explicit `drop()` as the `#[must_use]`'s annotation suggests (instead of the more general help line). Link: https://github.com/rust-lang/rust/issues/104253 [1] Link: https://github.com/rust-lang/rust/pull/112529 [2] Reviewed-by: Martin Rodriguez Reboredo Reviewed-by: Gary Guo Reviewed-by: Alice Ryhl Reviewed-by: Andreas Hindborg Reviewed-by: Björn Roy Baron Link: https://lore.kernel.org/r/20230823160244.188033-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

rust: Ignore preserve-most functions

2024-01-25T23:35:41Z

commit bad098d76835c1379e1cf6afc935f8a7e050f83c upstream. Neither bindgen nor Rust know about the preserve-most calling convention, and Clang describes it as unstable. Since we aren't using functions with this calling convention from Rust, blocklist them. These functions are only added to the build when list hardening is enabled, which is likely why others didn't notice this yet. Signed-off-by: Matthew Maurer Reviewed-by: Martin Rodriguez Reboredo Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20231031201945.1412345-1-mmaurer@google.com [ Used Markdown for consistency with the other comments in the file. ] Signed-off-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

rust: docs: fix logo replacement

2023-10-19T14:40:00Z

The static files placement by `rustdoc` changed in Rust 1.67.0 [1], but the custom code we have to replace the logo in the generated HTML files did not get updated. Thus update it to have the Linux logo again in the output. Hopefully `rustdoc` will eventually support a custom logo from a local file [2], so that we do not need to maintain this hack on our side. Link: https://github.com/rust-lang/rust/pull/101702 [1] Link: https://github.com/rust-lang/rfcs/pull/3226 [2] Fixes: 3ed03f4da06e ("rust: upgrade to Rust 1.68.2") Cc: stable@vger.kernel.org Tested-by: Benno Lossin Reviewed-by: Andreas Hindborg Link: https://lore.kernel.org/r/20231018155527.1015059-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda

rust: fix bindgen build error with fstrict-flex-arrays

2023-10-12T20:58:52Z

Commit df8fc4e934c1 ("kbuild: Enable -fstrict-flex-arrays=3") enabled '-fstrict-flex-arrays=3' globally, but bindgen does not recognized this compiler option, triggering the following build error: error: unknown argument: '-fstrict-flex-arrays=3', err: true [ Miguel: Commit df8fc4e934c1 ("kbuild: Enable -fstrict-flex-arrays=3") did it so only conditionally (i.e. only if the C compiler supports it). This explains what Andrea was seeing: he was compiling with a modern enough GCC, which enables the option, but with an old enough Clang. Andrea confirmed this was the case: he was using Clang 14 with GCC 13; and that Clang 15 worked for him. While it is possible to construct code (see mailing list for an example I came up with) where this could break, it is fairly contrived, and anyway GCC-built kernels with Rust enabled should only be used for experimentation until we get support for `rustc_codegen_gcc` and/or GCC Rust. So let's add this for the time being in case it helps somebody. ] Add '-fstrict-flex-arrays' to the list of cflags that should be ignored by bindgen. Fixes: df8fc4e934c1 ("kbuild: Enable -fstrict-flex-arrays=3") Signed-off-by: Andrea Righi Tested-by: Gary Guo Link: https://lore.kernel.org/r/20230815065346.131387-1-andrea.righi@canonical.com Signed-off-by: Miguel Ojeda

rust: error: Markdown style nit

2023-10-12T20:58:52Z

This patch fixes a trivial markdown style nit in the `SAFETY` comment. Signed-off-by: Manmohan Shukla Reviewed-by: Alice Ryhl Reviewed-by: Jianguo Bao Reviewed-by: Vincenzo Palazzo Reviewed-by: Finn Behrens Reviewed-by: Benno Lossin Reviewed-by: Andreas Hindborg Fixes: c7e20faa5fca ("rust: error: Add Error::to_ptr()") Link: https://lore.kernel.org/r/20230906204857.85619-1-manmshuk@gmail.com Signed-off-by: Miguel Ojeda

rust: error: fix the description for `ECHILD`

2023-10-12T20:58:28Z

A mistake was made and the description of `ECHILD` is wrong (it reuses the description of `ENOEXEC`). This fixes it to reflect what's in `errno-base.h`. Signed-off-by: Wedson Almeida Filho Reviewed-by: Martin Rodriguez Reboredo Reviewed-by: Trevor Gross Reviewed-by: Finn Behrens Reviewed-by: Alice Ryhl Fixes: 266def2a0f5b ("rust: error: add codes from `errno-base.h`") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230930144958.46051-1-wedsonaf@gmail.com [ Use the plural, as noticed by Benno. ] Signed-off-by: Miguel Ojeda