pm24.git/scripts, branch rust-6.10

rust: upgrade to Rust 1.78.0

2024-05-05T18:17:25Z

This is the next upgrade to the Rust toolchain, from 1.77.1 to 1.78.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"). It is much smaller than previous upgrades, since the `alloc` fork was dropped in commit 9d0441bab775 ("rust: alloc: remove our fork of the `alloc` crate") [3]. # Unstable features There have been no changes to the set of unstable features used in our own code. Therefore, the only unstable features allowed to be used outside the `kernel` crate is still `new_uninit`. However, since we finally dropped our `alloc` fork [3], all the unstable features used by `alloc` (~30 language ones, ~60 library ones) are not a concern anymore. This reduces the maintenance burden, increases the chances of new compiler versions working without changes and gets us closer to the goal of supporting several compiler versions. It also means that, ignoring non-language/library features, we are currently left with just the few language features needed to implement the kernel `Arc`, the `new_uninit` library feature, the `compiler_builtins` marker and the few `no_*` `cfg`s we pass when compiling `core`/`alloc`. Please see [4] for details. # Required changes ## LLVM's data layout Rust 1.77.0 (i.e. the previous upgrade) introduced a check for matching LLVM data layouts [5]. Then, Rust 1.78.0 upgraded LLVM's bundled major version from 17 to 18 [6], which changed the data layout in x86 [7]. Thus update the data layout in our custom target specification for x86 so that the compiler does not complain about the mismatch: error: data-layout for target `target-5559158138856098584`, `e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128`, differs from LLVM target's `x86_64-linux-gnu` default layout, `e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-i128:128-f80:128-n8:16:32:64-S128` In the future, the goal is to drop the custom target specifications. Meanwhile, if we want to support other LLVM versions used in `rustc` (e.g. for LTO), we will need to add some extra logic (e.g. conditional on LLVM's version, or extracting the data layout from an existing built-in target specification). ## `unused_imports` Rust's `unused_imports` lint covers both unused and redundant imports. Now, in 1.78.0, the lint detects more cases of redundant imports [8]. Thus one of the previous patches cleaned them up. ## Clippy's `new_without_default` Clippy now suggests to implement `Default` even when `new()` is `const`, since `Default::default()` may call `const` functions even if it is not `const` itself [9]. Thus one of the previous patches implemented it. # Other changes in Rust Rust 1.78.0 introduced `feature(asm_goto)` [10] [11]. This feature was discussed in the past [12]. Rust 1.78.0 introduced `feature(const_refs_to_static)` [13] to allow referencing statics in constants and extended `feature(const_mut_refs)` to allow raw mutable pointers in constants. Together, this should cover the kernel's `VTABLE` use case. In fact, the implementation [14] in upstream Rust added a test case for it [15]. Rust 1.78.0 with debug assertions enabled (i.e. `-Cdebug-assertions=y`, kernel's `CONFIG_RUST_DEBUG_ASSERTIONS=y`) now always checks all unsafe preconditions, though without a way to opt-out for particular cases [16]. It would be ideal to have a way to selectively disable certain checks per-call site for this one (i.e. not just per check but for particular instances of a check), even if the vast majority of the checks remain in place [17]. Rust 1.78.0 also improved a couple issues we reported when giving feedback for the new `--check-cfg` feature [18] [19]. # `alloc` upgrade and reviewing As mentioned above, compiler upgrades will not update `alloc` anymore, since we dropped our `alloc` fork [3]. Link: https://github.com/rust-lang/rust/blob/stable/RELEASES.md#version-1780-2024-05-02 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: https://lore.kernel.org/rust-for-linux/20240328013603.206764-1-wedsonaf@gmail.com/ [3] Link: https://github.com/Rust-for-Linux/linux/issues/2 [4] Link: https://github.com/rust-lang/rust/pull/120062 [5] Link: https://github.com/rust-lang/rust/pull/120055 [6] Link: https://reviews.llvm.org/D86310 [7] Link: https://github.com/rust-lang/rust/pull/117772 [8] Link: https://github.com/rust-lang/rust-clippy/pull/10903 [9] Link: https://github.com/rust-lang/rust/pull/119365 [10] Link: https://github.com/rust-lang/rust/issues/119364 [11] Link: https://lore.kernel.org/rust-for-linux/ZWipTZysC2YL7qsq@Boquns-Mac-mini.home/ [12] Link: https://github.com/rust-lang/rust/issues/119618 [13] Link: https://github.com/rust-lang/rust/pull/120932 [14] Link: https://github.com/rust-lang/rust/pull/120932/files#diff-e6fc1622c46054cd46b1d225c5386c5554564b3b0fa8a03c2dc2d8627a1079d9 [15] Link: https://github.com/rust-lang/rust/issues/120969 [16] Link: https://github.com/Rust-for-Linux/linux/issues/354 [17] Link: https://github.com/rust-lang/rust/pull/121202 [18] Link: https://github.com/rust-lang/rust/pull/121237 [19] Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20240401212303.537355-4-ojeda@kernel.org [ Added a few more details and links I mentioned in the list. - Miguel ] Signed-off-by: Miguel Ojeda

kbuild: use the upstream `alloc` crate

2024-04-16T20:03:14Z

Switch away from our fork of the `alloc` crate. We remove it altogether in the next commit. Signed-off-by: Wedson Almeida Filho Link: https://lore.kernel.org/r/20240328013603.206764-4-wedsonaf@gmail.com Signed-off-by: Miguel Ojeda

kbuild: rust: use `-Zdebuginfo-compression`

2024-04-02T15:41:22Z

Rust 1.74.0 introduced (unstable) support for the `-Zdebuginfo-compression` flag, thus use it. Note that the releases built by the Rust project (i.e. the ones provided by rustup) do not enable support for zstd in their bundled LLVM (yet, at least), thus the Rust compiler will warn, but the build will proceed: warning: unknown debuginfo compression algorithm zstd - will fall back to uncompressed debuginfo Link: https://github.com/rust-lang/rust/issues/120953 Link: https://github.com/rust-lang/rust/pull/115358 Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20240217002622.57322-1-ojeda@kernel.org [ Added note about zstd support in Rust-provided binaries. ] Signed-off-by: Miguel Ojeda

kbuild: rust: use `-Zdwarf-version` to support DWARFv5

2024-04-02T15:40:56Z

Rust 1.64.0 introduced (unstable) support for the `-Zdwarf-version` flag, which allows to select DWARFv5, thus use it. Link: https://github.com/rust-lang/rust/issues/103057 Link: https://github.com/rust-lang/rust/pull/98350 Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20240217002602.57270-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda

rust: upgrade to Rust 1.77.1

2024-03-29T19:12:30Z

This is the next upgrade to the Rust toolchain, from 1.76.0 to 1.77.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 The `offset_of` feature (single-field `offset_of!`) that we were using got stabilized in Rust 1.77.0 [3]. Therefore, now the only unstable features allowed to be used outside the `kernel` crate is `new_uninit`, though other code to be upstreamed may increase the list. Please see [4] for details. # Required changes Rust 1.77.0 merged the `unused_tuple_struct_fields` lint into `dead_code`, thus upgrading it from `allow` to `warn` [5]. In turn, this made `rustc` complain about the `ThisModule`'s pointer field being never read, but the previous patch adds the `as_ptr` method to it, needed by Binder [6], so that we do not need to locally `allow` it. # Other changes Rust 1.77.0 introduces the `--check-cfg` feature [7], for which there is a Call for Testing going on [8]. We were requested to test it and we found it useful [9] -- we will likely enable it in the future. # `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-1770-2024-03-21 [1] Link: https://rust-for-linux.com/rust-version-policy [2] Link: https://github.com/rust-lang/rust/pull/118799 [3] Link: https://github.com/Rust-for-Linux/linux/issues/2 [4] Link: https://github.com/rust-lang/rust/pull/118297 [5] Link: https://lore.kernel.org/rust-for-linux/20231101-rust-binder-v1-2-08ba9197f637@google.com/#Z31rust:kernel:lib.rs [6] Link: https://doc.rust-lang.org/nightly/unstable-book/compiler-flags/check-cfg.html [7] Link: https://github.com/rust-lang/rfcs/pull/3013#issuecomment-1936648479 [8] Link: https://github.com/rust-lang/rust/issues/82450#issuecomment-1947462977 [9] Reviewed-by: Alice Ryhl Tested-by: Boqun Feng Link: https://lore.kernel.org/r/20240217002717.57507-1-ojeda@kernel.org [ Upgraded to 1.77.1. Removed `allow(dead_code)` thanks to the previous patch. Reworded accordingly. No changes to `alloc` during the beta. ] Signed-off-by: Miguel Ojeda

Merge tag 'loongarch-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson

2024-03-22T17:22:45Z

Pull LoongArch updates from Huacai Chen: - Add objtool support for LoongArch - Add ORC stack unwinder support for LoongArch - Add kernel livepatching support for LoongArch - Select ARCH_HAS_CURRENT_STACK_POINTER in Kconfig - Select HAVE_ARCH_USERFAULTFD_MINOR in Kconfig - Some bug fixes and other small changes * tag 'loongarch-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson: LoongArch/crypto: Clean up useless assignment operations LoongArch: Define the __io_aw() hook as mmiowb() LoongArch: Remove superfluous flush_dcache_page() definition LoongArch: Move {dmw,tlb}_virt_to_page() definition to page.h LoongArch: Change __my_cpu_offset definition to avoid mis-optimization LoongArch: Select HAVE_ARCH_USERFAULTFD_MINOR in Kconfig LoongArch: Select ARCH_HAS_CURRENT_STACK_POINTER in Kconfig LoongArch: Add kernel livepatching support LoongArch: Add ORC stack unwinder support objtool: Check local label in read_unwind_hints() objtool: Check local label in add_dead_ends() objtool/LoongArch: Enable orc to be built objtool/x86: Separate arch-specific and generic parts objtool/LoongArch: Implement instruction decoder objtool/LoongArch: Enable objtool to be built

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

2024-03-21T21:41:00Z

Pull Kbuild updates from Masahiro Yamada: - Generate a list of built DTB files (arch/*/boot/dts/dtbs-list) - Use more threads when building Debian packages in parallel - Fix warnings shown during the RPM kernel package uninstallation - Change OBJECT_FILES_NON_STANDARD_*.o etc. to take a relative path to Makefile - Support GCC's -fmin-function-alignment flag - Fix a null pointer dereference bug in modpost - Add the DTB support to the RPM package - Various fixes and cleanups in Kconfig * tag 'kbuild-v6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: (67 commits) kconfig: tests: test dependency after shuffling choices kconfig: tests: add a test for randconfig with dependent choices kconfig: tests: support KCONFIG_SEED for the randconfig runner kbuild: rpm-pkg: add dtb files in kernel rpm kconfig: remove unneeded menu_is_visible() call in conf_write_defconfig() kconfig: check prompt for choice while parsing kconfig: lxdialog: remove unused dialog colors kconfig: lxdialog: fix button color for blackbg theme modpost: fix null pointer dereference kbuild: remove GCC's default -Wpacked-bitfield-compat flag kbuild: unexport abs_srctree and abs_objtree kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1 kconfig: remove named choice support kconfig: use linked list in get_symbol_str() to iterate over menus kconfig: link menus to a symbol kbuild: fix inconsistent indentation in top Makefile kbuild: Use -fmin-function-alignment when available alpha: merge two entries for CONFIG_ALPHA_GAMMA alpha: merge two entries for CONFIG_ALPHA_EV4 kbuild: change DTC_FLAGS_.o to take the path relative to $(obj) ...

Merge tag 'cocci-6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jlawall/linux

2024-03-21T17:17:10Z

Pull coccinelle update from Julia Lawall: "Simplify the device_attr_show semantic patch Also removes an unused variable warning" * tag 'cocci-6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/jlawall/linux: coccinelle: device_attr_show: Remove useless expression STR

kconfig: tests: test dependency after shuffling choices

2024-03-20T17:40:39Z

Commit c8fb7d7e48d1 ("kconfig: fix broken dependency in randconfig- generated .config") fixed the issue, but I did not add a test case. This commit adds a test case that emulates the reported situation. The test would fail without c8fb7d7e48d1. To handle the choice "choose X", FOO must be calculated beforehand. FOO depends on A, which is a member of another choice "choose A or B". Kconfig _temporarily_ assumes the value of A to proceed. The choice "choose A or B" will be shuffled later, but the result may or may not meet "FOO depends on A". Kconfig should invalidate the symbol values and recompute them. In the real example for ARCH=arm64, the choice "Instrumentation type" needs the value of CPU_BIG_ENDIAN. The choice "Endianness" will be shuffled later. Signed-off-by: Masahiro Yamada

kconfig: tests: add a test for randconfig with dependent choices

2024-03-20T17:39:55Z

Since commit 3b9a19e08960 ("kconfig: loop as long as we changed some symbols in randconfig"), conf_set_all_new_symbols() is repeated until there is no more choice left to be shuffled. The motivation was to shuffle a choice nested in another choice. Although commit 09d5873e4d1f ("kconfig: allow only 'config', 'comment', and 'if' inside 'choice'") disallowed the nested choice structure, we must still keep 3b9a19e08960 because there are still cases where conf_set_all_new_symbols() must iterate. scripts/kconfig/tests/choice_randomize/Kconfig is the test case. The second choice depends on 'B', which is the member of the first choice. With 3b9a19e08960 reverted, we would never get the pattern specified by scripts/kconfig/tests/choice_randomize/expected_config2. A real example can be found in lib/Kconfig.debug. Without 3b9a19e08960, the randconfig would not shuffle the "Compressed Debug information" choice, which depends on DEBUG_INFO, which is derived from another choice "Debug information". My goal is to refactor Kconfig so that randconfig will work more simply, without using the loop. For now, let's add a test case to ensure all dependent choices are shuffled, as it is a somewhat tricky case for the current Kconfig. Signed-off-by: Masahiro Yamada