pm24.git, branch rust-6.7

docs: rust: add "The Rust experiment" section

2023-10-25T01:14:00Z

Clarify that the Rust experiment is still going on to avoid confusion for both kernel maintainers and end users. Reviewed-by: Carlos Bilbao Link: https://lore.kernel.org/r/20231018160922.1018962-1-ojeda@kernel.org [ Changed last paragraph as discussed in the mailing list. ] Signed-off-by: Miguel Ojeda

x86: Enable IBT in Rust if enabled in C

2023-10-23T13:35:00Z

These flags are not made conditional on compiler support because at the moment exactly one version of rustc supported, and that one supports these flags. Building without these additional flags will manifest as objtool printing a large number of errors about missing ENDBR and if CFI is enabled (not currently possible) will result in incorrectly structured function prefixes. Signed-off-by: Matthew Maurer Reviewed-by: Nick Desaulniers Acked-by: "Peter Zijlstra (Intel)" Link: https://lore.kernel.org/r/20231009224347.2076221-1-mmaurer@google.com Signed-off-by: Miguel Ojeda

rust: Use grep -Ev rather than relying on GNU grep

2023-10-15T19:56:26Z

While GNU grep supports '\|' when in basic regular expression mode, not all grep implementations do (notably toybox grep, used to build the Android kernel, does not). Switching to grep -Ev enables extended regular expressions which includes support for the '|' operator. Signed-off-by: Matthew Maurer Reviewed-by: Martin Rodriguez Reboredo Reviewed-by: Trevor Gross Reviewed-by: Alice Ryhl Tested-by: Alice Ryhl Link: https://lore.kernel.org/r/20230928201421.2296518-1-mmaurer@google.com [ Reworded for typo. ] Signed-off-by: Miguel Ojeda

rust: Use awk instead of recent xargs

2023-10-15T19:48:24Z

`awk` is already required by the kernel build, and the `xargs` feature used in current Rust detection is not present in all `xargs` (notably, toybox based xargs, used in the Android kernel build). Signed-off-by: Matthew Maurer Reviewed-by: Alice Ryhl Tested-by: Alice Ryhl Reviewed-by: Martin Rodriguez Reboredo Link: https://lore.kernel.org/r/20230928205045.2375899-1-mmaurer@google.com Signed-off-by: Miguel Ojeda

rust: upgrade to Rust 1.73.0

2023-10-15T19:25:08Z

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

rust: print: use explicit link in documentation

2023-10-15T19:25:08Z

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

rust: task: remove redundant explicit link

2023-10-15T19:25:08Z

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

rust: kernel: remove `#[allow(clippy::new_ret_no_self)]`

2023-10-05T19:16:13Z

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` [1][2]. The kernel nowadays uses Rust 1.72.1, thus remove the `#[allow]`. Signed-off-by: Gary Guo Reviewed-by: Alice Ryhl Reviewed-by: Benno Lossin Reviewed-by: Finn Behrens Reviewed-by: Martin Rodriguez Reboredo Link: https://github.com/rust-lang/rust-clippy/issues/7344 [1] Link: https://github.com/rust-lang/rust-clippy/pull/9733 [2] Link: https://lore.kernel.org/r/20230923024707.47610-1-gary@garyguo.net [ Reworded slightly and added a couple `Link`s. ] Signed-off-by: Miguel Ojeda

MAINTAINERS: add Maintainer Entry Profile field for Rust

2023-10-05T19:16:13Z

The `P:` field allows a URI, and we have been adding information on how to contribute to the Rust subsystem to our webpage for a while now (and other relevant topics, e.g. branches, third-party crates, Rust unstable features...). The webpage/document does not currently follow the headings of the Maintainer Entry Profile, but it does nevertheless answer some of the questions we have got so far from contributors and it covers partially some of the topics there. Thus link to our "Contributing" document [1]. Link: https://rust-for-linux.com/contributing [1] Reviewed-by: Andreas Hindborg Reviewed-by: Alice Ryhl Reviewed-by: Vincenzo Palazzo Reviewed-by: Benno Lossin Link: https://lore.kernel.org/r/20230830165949.127475-2-ojeda@kernel.org Signed-off-by: Miguel Ojeda

MAINTAINERS: update Rust webpage

2023-10-05T19:16:13Z

A few months ago we started a webpage for the Rust subsystem and the overall Rust for Linux project [1]. The current `W:` field of the Rust entry points to the GitHub repository, since originally we kept information in a `README.md` file that got rendered by GitHub when visiting that URL. That information was moved into the webpage and got expanded. The webpage is also nowadays the entry point to the project, and we pointed the "Website" GitHub metadata field to it. Thus update the `W:` field to point to the actual webpage. Link: https://rust-for-linux.com [1] Reviewed-by: Vincenzo Palazzo Reviewed-by: Andreas Hindborg Reviewed-by: Benno Lossin Reviewed-by: Alice Ryhl Reviewed-by: Geert Stappers Reviewed-by: Boqun Feng Link: https://lore.kernel.org/r/20230830165949.127475-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda