wireguard-linux/scripts, branch jd/bump-compilers

scripts: fix gfp-translate after ___GFP_*_BITS conversion to an enum

2024-09-02T00:59:01Z

Richard reports that since 772dd0342727c ("mm: enumerate all gfp flags"), gfp-translate is broken, as the bit numbers are implicit, leaving the shell script unable to extract them. Even more, some bits are now at a variable location, making it double extra hard to parse using a simple shell script. Use a brute-force approach to the problem by generating a small C stub that will use the enum to dump the interesting bits. As an added bonus, we are now able to identify invalid bits for a given configuration. As an added drawback, we cannot parse include files that predate this change anymore. Tough luck. Link: https://lkml.kernel.org/r/20240823163850.3791201-1-maz@kernel.org Fixes: 772dd0342727 ("mm: enumerate all gfp flags") Signed-off-by: Marc Zyngier Reported-by: Richard Weinberger Cc: Petr Tesařík Cc: Suren Baghdasaryan Signed-off-by: Andrew Morton

net: drop special comment style

2024-08-23T09:21:02Z

As we discussed in the room at netdevconf earlier this week, drop the requirement for special comment style for netdev. For checkpatch, the general check accepts both right now, so simply drop the special request there as well. Acked-by: Stephen Hemminger Signed-off-by: Johannes Berg Acked-by: Jakub Kicinski Signed-off-by: David S. Miller

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

2024-08-22T23:43:15Z

Pull Kbuild fixes from Masahiro Yamada: - Eliminate the fdtoverlay command duplication in scripts/Makefile.lib - Fix 'make compile_commands.json' for external modules - Ensure scripts/kconfig/merge_config.sh handles missing newlines - Fix some build errors on macOS * tag 'kbuild-fixes-v6.11-2' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kbuild: fix typos "prequisites" to "prerequisites" Documentation/llvm: turn make command for ccache into code block kbuild: avoid scripts/kallsyms parsing /dev/null treewide: remove unnecessary inclusion scripts: kconfig: merge_config: config files: add a trailing newline Makefile: add $(srctree) to dependency of compile_commands.json target kbuild: clean up code duplication in cmd_fdtoverlay

kbuild: fix typos "prequisites" to "prerequisites"

2024-08-22T17:41:02Z

This typo in scripts/Makefile.build has been present for more than 20 years. It was accidentally copy-pasted to other scripts/Makefile.* files. Fix them all. Signed-off-by: Masahiro Yamada Reviewed-by: Nathan Chancellor

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

2024-08-16T18:24:06Z

Pull rust fixes from Miguel Ojeda: - Fix '-Os' Rust 1.80.0+ builds adding more intrinsics (also tweaked in upstream Rust for the upcoming 1.82.0). - Fix support for the latest version of rust-analyzer due to a change on rust-analyzer config file semantics (considered a fix since most developers use the latest version of the tool, which is the only one actually supported by upstream). I am discussing stability of the config file with upstream -- they may be able to start versioning it. - Fix GCC 14 builds due to '-fmin-function-alignment' not skipped for libclang (bindgen). - A couple Kconfig fixes around '{RUSTC,BINDGEN}_VERSION_TEXT' to suppress error messages in a foreign architecture chroot and to use a proper default format. - Clean 'rust-analyzer' target warning due to missing recursive make invocation mark. - Clean Clippy warning due to missing indentation in docs. - Clean LLVM 19 build warning due to removed 3dnow feature upstream. * tag 'rust-fixes-6.11' of https://github.com/Rust-for-Linux/linux: rust: x86: remove `-3dnow{,a}` from target features kbuild: rust-analyzer: mark `rust_is_available.sh` invocation as recursive rust: add intrinsics to fix `-Os` builds kbuild: rust: skip -fmin-function-alignment in bindgen flags rust: Support latest version of `rust-analyzer` rust: macros: indent list item in `module!`'s docs rust: fix the default format for CONFIG_{RUSTC,BINDGEN}_VERSION_TEXT rust: suppress error messages from CONFIG_{RUSTC,BINDGEN}_VERSION_TEXT

Merge tag 'hardening-v6.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

2024-08-15T18:50:07Z

Pull hardening fixes from Kees Cook: - gcc-plugins: randstruct: Remove GCC 4.7 or newer requirement (Thorsten Blum) - kallsyms: Clean up interaction with LTO suffixes (Song Liu) - refcount: Report UAF for refcount_sub_and_test(0) when counter==0 (Petr Pavlu) - kunit/overflow: Avoid misallocation of driver name (Ivan Orlov) * tag 'hardening-v6.11-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: kallsyms: Match symbols exactly with CONFIG_LTO_CLANG kallsyms: Do not cleanup .llvm. suffix before sorting symbols kunit/overflow: Fix UB in overflow_allocation_test gcc-plugins: randstruct: Remove GCC 4.7 or newer requirement refcount: Report UAF for refcount_sub_and_test(0) when counter==0

kallsyms: Do not cleanup .llvm. suffix before sorting symbols

2024-08-15T16:33:34Z

Cleaning up the symbols causes various issues afterwards. Let's sort the list based on original name. Signed-off-by: Song Liu Fixes: 8cc32a9bbf29 ("kallsyms: strip LTO-only suffixes from promoted global functions") Reviewed-by: Masami Hiramatsu (Google) Tested-by: Masami Hiramatsu (Google) Acked-by: Petr Mladek Reviewed-by: Sami Tolvanen Reviewed-by: Luis Chamberlain Link: https://lore.kernel.org/r/20240807220513.3100483-2-song@kernel.org Signed-off-by: Kees Cook

kbuild: avoid scripts/kallsyms parsing /dev/null

2024-08-12T09:37:27Z

On macOS, as reported by Daniel Gomez, getline() sets ENOTTY to errno if it is requested to read from /dev/null. If this is worth fixing, I would rather pass an empty file to scripts/kallsyms instead of adding the ugly #ifdef __APPLE__. Fixes: c442db3f49f2 ("kbuild: remove PROVIDE() for kallsyms symbols") Reported-by: Daniel Gomez Closes: https://lore.kernel.org/all/20240807-macos-build-support-v1-12-4cd1ded85694@samsung.com/ Signed-off-by: Masahiro Yamada Reviewed-by: Nicolas Schier Reviewed-by: Daniel Gomez

rust: x86: remove `-3dnow{,a}` from target features

2024-08-09T22:05:10Z

LLVM 19 is dropping support for 3DNow! in commit f0eb5587ceeb ("Remove support for 3DNow!, both intrinsics and builtins. (#96246)"): Remove support for 3DNow!, both intrinsics and builtins. (#96246) This set of instructions was only supported by AMD chips starting in the K6-2 (introduced 1998), and before the "Bulldozer" family (2011). They were never much used, as they were effectively superseded by the more-widely-implemented SSE (first implemented on the AMD side in Athlon XP in 2001). This is being done as a predecessor towards general removal of MMX register usage. Since there is almost no usage of the 3DNow! intrinsics, and no modern hardware even implements them, simple removal seems like the best option. Thus we should avoid passing these to the backend, since otherwise we get a diagnostic about it: '-3dnow' is not a recognized feature for this target (ignoring feature) '-3dnowa' is not a recognized feature for this target (ignoring feature) We could try to disable them only up to LLVM 19 (not the C side one, but the one used by `rustc`, which may be built with a range of LLVMs). However, to avoid more complexity, we can likely just remove them altogether. According to Nikita [2]: > I don't think it's needed because LLVM should not generate 3dnow > instructions unless specifically asked to, using intrinsics that > Rust does not provide in the first place. Thus do so, like Rust did for one of their builtin targets [3]. For those curious: Clang will warn only about trying to enable them (`-m3dnow{,a}`), but not about disabling them (`-mno-3dnow{,a}`), so there is no change needed there. Cc: Nikita Popov Cc: Nathan Chancellor Cc: x86@kernel.org Link: https://github.com/llvm/llvm-project/commit/f0eb5587ceeb641445b64cb264c822b4751de04a [1] Link: https://github.com/rust-lang/rust/pull/127864#issuecomment-2235898760 [2] Link: https://github.com/rust-lang/rust/pull/127864 [3] Closes: https://github.com/Rust-for-Linux/linux/issues/1094 Tested-by: Benno Lossin Tested-by: Alice Ryhl Link: https://lore.kernel.org/r/20240806144558.114461-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda

rust: Support latest version of `rust-analyzer`

2024-08-06T23:16:52Z

Sets the `sysroot` field in rust-project.json which is now needed in newer versions of rust-analyzer instead of the `sysroot_src` field. Till [1] `rust-analyzer` used to guess the `sysroot` based on the `sysroot_src` at [2]. Now `sysroot` is a required parameter for a `rust-project.json` file. It is required because `rust-analyzer` need it to find the proc-macro server [3]. In the current version of `rust-analyzer` the `sysroot_src` is only used to include the inbuilt library crates (std, core, alloc, etc) [4]. Since we already specify the core library to be included in the `rust-project.json` we don't need to define the `sysroot_src`. Code editors like VS Code try to use the latest version of rust-analyzer (which is updated every week) instead of the version of rust-analyzer that comes with the rustup toolchain (which is updated every six weeks along with the rust version). Without this change `rust-analyzer` is breaking for anyone using VS Code. As they are getting the latest version of `rust-analyzer` with the changes made in [1]. `rust-analyzer` will also start breaking for other developers as they update their rust version (assuming that also updates the rust-analyzer version on their system). This patch should work with every setup as there is no more guess work being done by `rust-analyzer`. [ Lukas, who leads the rust-analyzer team, says: `sysroot_src` is required now if you want to have the sysroot source libraries be loaded. I think we used to infer it as `{sysroot}/lib/rustlib/src/rust/library` before when only the `sysroot` field was given but that was since changed to make it possible in having a sysroot without the standard library sources (that is only have the binaries available). So if you want the library sources to be loaded by rust-analyzer you will have to set that field as well now. - Miguel ] Link: https://github.com/rust-lang/rust-analyzer/pull/17287 [1] Link: https://github.com/rust-lang/rust-analyzer/blob/f372a8a1176ff8dd5f45ab2ddd45f3530db0374f/crates/project-model/src/workspace.rs#L367-L374 [2] Link: https://github.com/rust-lang/rust-analyzer/blob/eeb192b79aeac47b40add66347022af17a74fbaf/crates/project-model/src/sysroot.rs#L180-L192 [3] Link: https://github.com/search?q=repo%3AVeykril%2Frust-analyzer%20src_root()&type=code [4] Tested-by: Dirk Behme Signed-off-by: Sarthak Singh Link: https://rust-for-linux.zulipchat.com/#narrow/stream/291565-Help/topic/How.20to.20rust-analyzer.20correctly.20working Link: https://lore.kernel.org/r/20240724172713.899399-1-sarthak.singh99@gmail.com [ Formatted comment, fixed typo and removed spurious empty line. - Miguel ] Signed-off-by: Miguel Ojeda