user/sven/linux.git/Makefile, branch v6.6.37

Linux 6.6.37

2024-07-05T07:34:07Z

Link: https://lore.kernel.org/r/20240702170233.048122282@linuxfoundation.org Tested-by: SeongJae Park Tested-by: Mark Brown Tested-by: Shuah Khan Tested-by: Jon Hunter Tested-by: Takeshi Ogasawara Tested-by: Peter Schneider Tested-by: Kelsey Steele Tested-by: Ron Economos Tested-by: Florian Fainelli Signed-off-by: Greg Kroah-Hartman

Linux 6.6.36

2024-06-27T11:49:15Z

Link: https://lore.kernel.org/r/20240625085537.150087723@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Peter Schneider Tested-by: Takeshi Ogasawara Tested-by: SeongJae Park Tested-by: Shuah Khan Tested-by: kernelci.org bot Tested-by: Ron Economos Tested-by: Kelsey Steele Signed-off-by: Greg Kroah-Hartman

Linux 6.6.35

2024-06-21T12:38:50Z

Link: https://lore.kernel.org/r/20240619125606.345939659@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Harshit Mogalapalli Tested-by: SeongJae Park Tested-by: Jon Hunter Tested-by: Allen Pais Tested-by: Kelsey Steele Tested-by: Mark Brown Tested-by: Takeshi Ogasawara Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Peter Schneider Tested-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman

Linux 6.6.34

2024-06-16T11:47:49Z

Link: https://lore.kernel.org/r/20240613113223.281378087@linuxfoundation.org Tested-by: Takeshi Ogasawara Tested-by: SeongJae Park Tested-by: Ron Economos Tested-by: Mark Brown Tested-by: Jon Hunter Tested-by: Harshit Mogalapalli Tested-by: Peter Schneider Tested-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman

kbuild: Remove support for Clang's ThinLTO caching

2024-06-16T11:47:40Z

commit aba091547ef6159d52471f42a3ef531b7b660ed8 upstream. There is an issue in clang's ThinLTO caching (enabled for the kernel via '--thinlto-cache-dir') with .incbin, which the kernel occasionally uses to include data within the kernel, such as the .config file for /proc/config.gz. For example, when changing the .config and rebuilding vmlinux, the copy of .config in vmlinux does not match the copy of .config in the build folder: $ echo 'CONFIG_LTO_NONE=n CONFIG_LTO_CLANG_THIN=y CONFIG_IKCONFIG=y CONFIG_HEADERS_INSTALL=y' >kernel/configs/repro.config $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 clean defconfig repro.config vmlinux ... $ grep CONFIG_HEADERS_INSTALL .config CONFIG_HEADERS_INSTALL=y $ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL CONFIG_HEADERS_INSTALL=y $ scripts/config -d HEADERS_INSTALL $ make -kj"$(nproc)" ARCH=x86_64 LLVM=1 vmlinux ... UPD kernel/config_data GZIP kernel/config_data.gz CC kernel/configs.o ... LD vmlinux ... $ grep CONFIG_HEADERS_INSTALL .config # CONFIG_HEADERS_INSTALL is not set $ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL CONFIG_HEADERS_INSTALL=y Without '--thinlto-cache-dir' or when using full LTO, this issue does not occur. Benchmarking incremental builds on a few different machines with and without the cache shows a 20% increase in incremental build time without the cache when measured by touching init/main.c and running 'make all'. ARCH=arm64 defconfig + CONFIG_LTO_CLANG_THIN=y on an arm64 host: Benchmark 1: With ThinLTO cache Time (mean ± σ): 56.347 s ± 0.163 s [User: 83.768 s, System: 24.661 s] Range (min … max): 56.109 s … 56.594 s 10 runs Benchmark 2: Without ThinLTO cache Time (mean ± σ): 67.740 s ± 0.479 s [User: 718.458 s, System: 31.797 s] Range (min … max): 67.059 s … 68.556 s 10 runs Summary With ThinLTO cache ran 1.20 ± 0.01 times faster than Without ThinLTO cache ARCH=x86_64 defconfig + CONFIG_LTO_CLANG_THIN=y on an x86_64 host: Benchmark 1: With ThinLTO cache Time (mean ± σ): 85.772 s ± 0.252 s [User: 91.505 s, System: 8.408 s] Range (min … max): 85.447 s … 86.244 s 10 runs Benchmark 2: Without ThinLTO cache Time (mean ± σ): 103.833 s ± 0.288 s [User: 232.058 s, System: 8.569 s] Range (min … max): 103.286 s … 104.124 s 10 runs Summary With ThinLTO cache ran 1.21 ± 0.00 times faster than Without ThinLTO cache While it is unfortunate to take this performance improvement off the table, correctness is more important. If/when this is fixed in LLVM, it can potentially be brought back in a conditional manner. Alternatively, a developer can just disable LTO if doing incremental compiles quickly is important, as a full compile cycle can still take over a minute even with the cache and it is unlikely that LTO will result in functional differences for a kernel change. Cc: stable@vger.kernel.org Fixes: dc5723b02e52 ("kbuild: add support for Clang LTO") Reported-by: Yifan Hong Closes: https://github.com/ClangBuiltLinux/linux/issues/2021 Reported-by: Masami Hiramatsu Closes: https://lore.kernel.org/r/20220327115526.cc4b0ff55fc53c97683c3e4d@kernel.org/ Signed-off-by: Nathan Chancellor Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

Linux 6.6.33

2024-06-12T09:13:03Z

Link: https://lore.kernel.org/r/20240606131732.440653204@linuxfoundation.org Tested-by: SeongJae Park Tested-by: Shuah Khan Tested-by: Jon Hunter Tested-by: Takeshi Ogasawara Tested-by: Conor Dooley Tested-by: Mark Brown Tested-by: Allen Pais Tested-by: Ron Economos Link: https://lore.kernel.org/r/20240609113903.732882729@linuxfoundation.org Tested-by: Takeshi Ogasawara Tested-by: SeongJae Park Tested-by: Jon Hunter Tested-by: Mark Brown Tested-by: kernelci.org bot Tested-by: Kelsey Steele Signed-off-by: Greg Kroah-Hartman

kbuild: unify vdso_install rules

2024-06-12T09:12:32Z

[ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ] Currently, there is no standard implementation for vdso_install, leading to various issues: 1. Code duplication Many architectures duplicate similar code just for copying files to the install destination. Some architectures (arm, sparc, x86) create build-id symlinks, introducing more code duplication. 2. Unintended updates of in-tree build artifacts The vdso_install rule depends on the vdso files to install. It may update in-tree build artifacts. This can be problematic, as explained in commit 19514fc665ff ("arm, kbuild: make "make install" not depend on vmlinux"). 3. Broken code in some architectures Makefile code is often copied from one architecture to another without proper adaptation. 'make vdso_install' for parisc does not work. 'make vdso_install' for s390 installs vdso64, but not vdso32. To address these problems, this commit introduces a generic vdso_install rule. Architectures that support vdso_install need to define vdso-install-y in arch/*/Makefile. vdso-install-y lists the files to install. For example, arch/x86/Makefile looks like this: vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix, if exists, stripped away. vdso-install-y can optionally take the second field after the colon separator. This is needed because some architectures install a vdso file as a different base name. The following is a snippet from arch/arm64/Makefile. vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so This will rename vdso.so.dbg to vdso32.so during installation. If such architectures change their implementation so that the base names match, this workaround will go away. Signed-off-by: Masahiro Yamada Acked-by: Sven Schnelle # s390 Reviewed-by: Nicolas Schier Reviewed-by: Guo Ren Acked-by: Helge Deller # parisc Acked-by: Catalin Marinas Acked-by: Russell King (Oracle) Stable-dep-of: fc2f5f10f9bc ("s390/vdso: Create .build-id links for unstripped vdso files") Signed-off-by: Sasha Levin

Linux 6.6.32

2024-05-25T14:22:56Z

Link: https://lore.kernel.org/r/20240523130342.462912131@linuxfoundation.org Tested-by: SeongJae Park Tested-by: Mark Brown Tested-by: Florian Fainelli Tested-by: Takeshi Ogasawara Tested-by: Linux Kernel Functional Testing Tested-by: Harshit Mogalapalli Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Jon Hunter Tested-by: Ron Economos Tested-by: Kelsey Steele Signed-off-by: Greg Kroah-Hartman

Linux 6.6.31

2024-05-17T10:02:40Z

Link: https://lore.kernel.org/r/20240514101032.219857983@linuxfoundation.org Tested-by: Takeshi Ogasawara Tested-by: Miguel Ojeda Tested-by: Harshit Mogalapalli Tested-by: Allen Pais Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Conor Dooley Link: https://lore.kernel.org/r/20240515082510.431870507@linuxfoundation.org Tested-by: Takeshi Ogasawara Tested-by: Mark Brown Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: Allen Pais Tested-by: Jon Hunter Link: https://lore.kernel.org/r/20240516121335.906510573@linuxfoundation.org Tested-by: Mark Brown Tested-by: Florian Fainelli Tested-by: SeongJae Park Tested-by: kernelci.org bot Tested-by: Allen Pais Tested-by: Takeshi Ogasawara Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Signed-off-by: Greg Kroah-Hartman

Linux 6.6.30

2024-05-02T14:32:50Z

Link: https://lore.kernel.org/r/20240430103058.010791820@linuxfoundation.org Tested-by: Harshit Mogalapalli Tested-by: SeongJae Park Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Miguel Ojeda Tested-by: Takeshi Ogasawara Tested-by: Jon Hunter Tested-by: Mark Brown Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Pascal Ernster Signed-off-by: Greg Kroah-Hartman