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

rust: Ignore preserve-most functions

2024-01-25T23:45:09Z

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

Merge tag 'kbuild-v6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild

2023-11-04T18:07:19Z

Pull Kbuild updates from Masahiro Yamada: - Implement the binary search in modpost for faster symbol lookup - Respect HOSTCC when linking host programs written in Rust - Change the binrpm-pkg target to generate kernel-devel RPM package - Fix endianness issues for tee and ishtp MODULE_DEVICE_TABLE - Unify vdso_install rules - Remove unused __memexit* annotations - Eliminate stale whitelisting for __devinit/__devexit from modpost - Enable dummy-tools to handle the -fpatchable-function-entry flag - Add 'userldlibs' syntax * tag 'kbuild-v6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (30 commits) kbuild: support 'userldlibs' syntax kbuild: dummy-tools: pretend we understand -fpatchable-function-entry kbuild: Correct missing architecture-specific hyphens modpost: squash ALL_{INIT,EXIT}_TEXT_SECTIONS to ALL_TEXT_SECTIONS modpost: merge sectioncheck table entries regarding init/exit sections modpost: use ALL_INIT_SECTIONS for the section check from DATA_SECTIONS modpost: disallow the combination of EXPORT_SYMBOL and __meminit* modpost: remove EXIT_SECTIONS macro modpost: remove MEM_INIT_SECTIONS macro modpost: remove more symbol patterns from the section check whitelist modpost: disallow *driver to reference .meminit* sections linux/init: remove __memexit* annotations modpost: remove ALL_EXIT_DATA_SECTIONS macro kbuild: simplify cmd_ld_multi_m kbuild: avoid too many execution of scripts/pahole-flags.sh kbuild: remove ARCH_POSTLINK from module builds kbuild: unify no-compiler-targets and no-sync-config-targets kbuild: unify vdso_install rules docs: kbuild: add INSTALL_DTBS_PATH UML: remove unused cmd_vdso_install ...

Merge tag 'wq-for-6.7-rust-bindings' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq

2023-10-31T06:35:48Z

Pull workqueue rust bindings from Tejun Heo: "Add rust bindings to allow rust code to schedule work items on workqueues. While the current bindings don't cover all of the workqueue API, it provides enough for basic usage and can be expanded as needed" * tag 'wq-for-6.7-rust-bindings' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: rust: workqueue: add examples rust: workqueue: add `try_spawn` helper method rust: workqueue: implement `WorkItemPointer` for pointer types rust: workqueue: add helper for defining work_struct fields rust: workqueue: define built-in queues rust: workqueue: add low-level workqueue bindings rust: sync: add `Arc::{from_raw, into_raw}`

Merge tag 'rust-6.7' of https://github.com/Rust-for-Linux/linux

2023-10-31T06:30:49Z

Pull rust updates from Miguel Ojeda: "A small one compared to the previous one in terms of features. In terms of lines, as usual, the 'alloc' version upgrade accounts for most of them. Toolchain and infrastructure: - Upgrade to Rust 1.73.0 This time around, due to how the kernel and Rust schedules have aligned, there are two upgrades in fact. They contain the fixes for a few issues we reported to the Rust project. In addition, a few cleanups indicated by the upgraded compiler or possible thanks to it. For instance, the compiler now detects redundant explicit links. - A couple changes to the Rust 'Makefile' so that it can be used with toybox tools, allowing Rust to be used in the Android kernel build. x86: - Enable IBT if enabled in C Documentation: - Add "The Rust experiment" section to the Rust index page MAINTAINERS: - Add Maintainer Entry Profile field ('P:'). - Update our 'W:' field to point to the webpage we have been building this year" * tag 'rust-6.7' of https://github.com/Rust-for-Linux/linux: docs: rust: add "The Rust experiment" section x86: Enable IBT in Rust if enabled in C rust: Use grep -Ev rather than relying on GNU grep rust: Use awk instead of recent xargs rust: upgrade to Rust 1.73.0 rust: print: use explicit link in documentation rust: task: remove redundant explicit link rust: kernel: remove `#[allow(clippy::new_ret_no_self)]` MAINTAINERS: add Maintainer Entry Profile field for Rust MAINTAINERS: update Rust webpage rust: upgrade to Rust 1.72.1 rust: arc: add explicit `drop()` around `Box::from_raw()`

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: 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