pm24.git/scripts, branch rust-6.13

rust: warn on bindgen < 0.69.5 and libclang >= 19.1

2024-11-12T20:26:54Z

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]. Cc: Ben Beasley Cc: NoisyCoil Cc: Matthias Geiger Link: https://lore.kernel.org/rust-for-linux/20241030-bindgen-libclang-warn-v1-1-3a7ba9fedcfe@google.com/ [1] Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1086510 [2] Link: https://bugs.launchpad.net/ubuntu/+source/rust-bindgen-cli/+bug/2086639 [3] Link: https://github.com/Rust-for-Linux/linux/issues/1127 [4] Co-developed-by: Alice Ryhl Signed-off-by: Alice Ryhl Link: https://lore.kernel.org/r/20241111201607.653149-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda

kbuild: rust: remove the `alloc` crate and `GlobalAlloc`

2024-10-15T21:10:32Z

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`. Signed-off-by: Danilo Krummrich Link: https://lore.kernel.org/r/20241004154149.93856-29-dakr@kernel.org Signed-off-by: Miguel Ojeda

rust: enable arbitrary_self_types and remove `Receiver`

2024-10-07T19:39:57Z

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). Cc: Adrian Taylor Link: https://github.com/rust-lang/rfcs/pull/3519 [1] Link: https://github.com/rust-lang/rust/issues/44874 [2] Signed-off-by: Gary Guo Reviewed-by: Benno Lossin Reviewed-by: Alice Ryhl Link: https://lore.kernel.org/r/20240915132734.1653004-1-gary@garyguo.net Signed-off-by: Miguel Ojeda

rust: start using the `#[expect(...)]` attribute

2024-10-07T19:39:57Z

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: #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wunused-function" static void f(void) {} #pragma GCC diagnostic pop But way less verbose: #[allow(dead_code)] fn f() {} 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]. Cc: Fridtjof Stoldt Cc: Urgau Link: https://rust-lang.github.io/rfcs/2383-lint-reasons.html#expect-lint-attribute [1] Link: https://github.com/rust-lang/rust/issues/54503 [2] Link: https://github.com/rust-lang/rust/issues/114557 [3] Reviewed-by: Alice Ryhl Reviewed-by: Trevor Gross Tested-by: Gary Guo Reviewed-by: Gary Guo Link: https://lore.kernel.org/r/20240904204347.168520-18-ojeda@kernel.org Signed-off-by: Miguel Ojeda

kbuild: deb-pkg: Remove blank first line from maint scripts

2024-10-06T17:36:38Z

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 Reviewed-by: Nathan Chancellor Reviewed-by: Nicolas Schier Signed-off-by: Masahiro Yamada

scripts: import more list macros

2024-10-06T17:12:27Z

Import list_is_first, list_is_last, list_replace, and list_replace_init. Signed-off-by: Sami Tolvanen Signed-off-by: Masahiro Yamada

kconfig: qconf: fix buffer overflow in debug links

2024-10-02T07:02:40Z

If you enable "Option -> Show Debug Info" and click a link, the program terminates with the following error: *** buffer overflow detected ***: terminated The buffer overflow is caused by the following line: strcat(data, "$"); The buffer needs one more byte to accommodate the additional character. Fixes: c4f7398bee9c ("kconfig: qconf: make debug links work again") Signed-off-by: Masahiro Yamada

kconfig: qconf: move conf_read() before drawing tree pain

2024-10-01T08:05:34Z

The constructor of ConfigMainWindow() calls show*View(), which needs to calculate symbol values. conf_read() must be called before that. Fixes: 060e05c3b422 ("kconfig: qconf: remove initial call to conf_changed()") Signed-off-by: Masahiro Yamada

kconfig: clear expr::val_is_valid when allocated

2024-10-01T08:05:30Z

Since commit 95573cac25c6 ("kconfig: cache expression values"), xconfig emits a lot of false-positive "unmet direct dependencies" warnings. While conf_read() clears val_is_valid flags, 'make xconfig' calculates symbol values even before the conf_read() call. This is another issue that should be addressed separately, but it has revealed that the val_is_valid field is not initialized. Fixes: 95573cac25c6 ("kconfig: cache expression values") Signed-off-by: Masahiro Yamada

kconfig: fix infinite loop in sym_calc_choice()

2024-09-30T11:42:52Z

Since commit f79dc03fe68c ("kconfig: refactor choice value calculation"), Kconfig for ARCH=powerpc may result in an infinite loop. This occurs because there are two entries for POWERPC64_CPU in a choice block. If the same symbol appears twice in a choice block, the ->choice_link node is added twice to ->choice_members, resulting a corrupted linked list. A simple test case is: choice prompt "choice" config A bool "A" config B bool "B 1" config B bool "B 2" endchoice Running 'make defconfig' results in an infinite loop. One solution is to replace the current two entries: config POWERPC64_CPU bool "Generic (POWER5 and PowerPC 970 and above)" depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN select PPC_64S_HASH_MMU config POWERPC64_CPU bool "Generic (POWER8 and above)" depends on PPC_BOOK3S_64 && CPU_LITTLE_ENDIAN select ARCH_HAS_FAST_MULTIPLIER select PPC_64S_HASH_MMU select PPC_HAS_LBARX_LHARX with the following single entry: config POWERPC64_CPU bool "Generic 64 bit powerpc" depends on PPC_BOOK3S_64 select ARCH_HAS_FAST_MULTIPLIER if CPU_LITTLE_ENDIAN select PPC_64S_HASH_MMU select PPC_HAS_LBARX_LHARX if CPU_LITTLE_ENDIAN In my opinion, the latter looks cleaner, but PowerPC maintainers may prefer to display different prompts depending on CPU_LITTLE_ENDIAN. For now, this commit fixes the issue in Kconfig, restoring the original behavior. I will reconsider whether such a use case is worth supporting. Fixes: f79dc03fe68c ("kconfig: refactor choice value calculation") Reported-by: Marco Bonelli Closes: https://lore.kernel.org/all/1763151587.3581913.1727224126288@privateemail.com/ Signed-off-by: Masahiro Yamada