user/sven/linux.git/Makefile, branch v5.10.141

Linux 5.10.141

2022-09-05T08:28:59Z

Link: https://lore.kernel.org/r/20220902121359.177846782@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Guenter Roeck Tested-by: Rudi Heitbaum Tested-by: Linux Kernel Functional Testing Tested-by: Salvatore Bonaccorso Tested-by: Sudip Mukherjee Tested-by: Pavel Machek (CIP) Signed-off-by: Greg Kroah-Hartman

Linux 5.10.140

2022-08-31T15:15:24Z

Link: https://lore.kernel.org/r/20220829105756.500128871@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Slade Watkins Tested-by: Pavel Machek (CIP) Tested-by: Salvatore Bonaccorso Tested-by: Shuah Khan Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Tested-by: Sudip Mukherjee Tested-by: Rudi Heitbaum Signed-off-by: Greg Kroah-Hartman

Linux 5.10.139

2022-08-29T09:31:49Z

Signed-off-by: Greg Kroah-Hartman

Linux 5.10.138

2022-08-25T09:38:24Z

Link: https://lore.kernel.org/r/20220823080059.091088642@linuxfoundation.org Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20220824065913.068916566@linuxfoundation.org Tested-by: Ron Economos Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

kbuild: fix the modules order between drivers and libs

2022-08-25T09:38:09Z

commit 113147510b48e764e624e3d0e6707a1e48bc05a9 upstream. Commit b2c885549122 ("kbuild: update modules.order only when contained modules are updated") accidentally changed the modules order. Prior to that commit, the modules order was determined based on vmlinux-dirs, which lists core-y/m, drivers-y/m, libs-y/m, in this order. Now, subdir-modorder lists them in a different order: core-y/m, libs-y/m, drivers-y/m. Presumably, there was no practical issue because the modules in drivers and libs are orthogonal, but there is no reason to have this distortion. Get back to the original order. Fixes: b2c885549122 ("kbuild: update modules.order only when contained modules are updated") Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

Linux 5.10.137

2022-08-21T13:16:27Z

Link: https://lore.kernel.org/r/20220819153829.135562864@linuxfoundation.org Tested-by: Shuah Khan Tested-by: Rudi Heitbaum Tested-by: Sudip Mukherjee Tested-by: Pavel Machek (CIP) Tested-by: Salvatore Bonaccorso Link: https://lore.kernel.org/r/20220820182952.751374248@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

Makefile: link with -z noexecstack --no-warn-rwx-segments

2022-08-21T13:15:18Z

commit 0d362be5b14200b77ecc2127936a5ff82fbffe41 upstream. Users of GNU ld (BFD) from binutils 2.39+ will observe multiple instances of a new warning when linking kernels in the form: ld: warning: vmlinux: missing .note.GNU-stack section implies executable stack ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker ld: warning: vmlinux has a LOAD segment with RWX permissions Generally, we would like to avoid the stack being executable. Because there could be a need for the stack to be executable, assembler sources have to opt-in to this security feature via explicit creation of the .note.GNU-stack feature (which compilers create by default) or command line flag --noexecstack. Or we can simply tell the linker the production of such sections is irrelevant and to link the stack as --noexecstack. LLVM's LLD linker defaults to -z noexecstack, so this flag isn't strictly necessary when linking with LLD, only BFD, but it doesn't hurt to be explicit here for all linkers IMO. --no-warn-rwx-segments is currently BFD specific and only available in the current latest release, so it's wrapped in an ld-option check. While the kernel makes extensive usage of ELF sections, it doesn't use permissions from ELF segments. Link: https://lore.kernel.org/linux-block/3af4127a-f453-4cf7-f133-a181cce06f73@kernel.dk/ Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107 Link: https://github.com/llvm/llvm-project/issues/57009 Reported-and-tested-by: Jens Axboe Suggested-by: Fangrui Song Signed-off-by: Nick Desaulniers Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

Linux 5.10.136

2022-08-11T11:06:47Z

Link: https://lore.kernel.org/r/20220809175512.853274191@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Rudi Heitbaum Tested-by: Salvatore Bonaccorso Tested-by: Sudip Mukherjee Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman

Linux 5.10.135

2022-08-03T10:00:52Z

Link: https://lore.kernel.org/r/20220801114133.641770326@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Guenter Roeck Tested-by: Rudi Heitbaum Tested-by: Pavel Machek (CIP) Tested-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

Linux 5.10.134

2022-07-29T15:19:29Z

Link: https://lore.kernel.org/r/20220727161012.056867467@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Linux Kernel Functional Testing Tested-by: Pavel Machek (CIP) Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Sudip Mukherjee Link: https://lore.kernel.org/r/20220728150340.045826831@linuxfoundation.org Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Tested-by: Sudip Mukherjee Tested-by: Rudi Heitbaum Signed-off-by: Greg Kroah-Hartman