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

Linux 5.15.64

2022-08-31T15:16:52Z

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

Linux 5.15.63

2022-08-25T09:40:49Z

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:40:27Z

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.15.62

2022-08-21T13:17:49Z

Link: https://lore.kernel.org/r/20220819153711.658766010@linuxfoundation.org Tested-by: Shuah Khan Tested-by: Bagas Sanjaya Tested-by: Sudip Mukherjee Tested-by: Ron Economos Link: https://lore.kernel.org/r/20220820182309.607584465@linuxfoundation.org Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

Linux 5.15.61

2022-08-17T12:24:32Z

Link: https://lore.kernel.org/r/20220815180337.130757997@linuxfoundation.org Tested-by: Shuah Khan Tested-by: Bagas Sanjaya Link: https://lore.kernel.org/r/20220816124544.577833376@linuxfoundation.org Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Tested-by: Ron Economos Signed-off-by: Greg Kroah-Hartman

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

2022-08-17T12:22:44Z

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.15.60

2022-08-11T11:07:54Z

Link: https://lore.kernel.org/r/20220809175514.276643253@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Bagas Sanjaya Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Ron Economos Signed-off-by: Greg Kroah-Hartman

Linux 5.15.59

2022-08-03T10:03:56Z

Link: https://lore.kernel.org/r/20220801114134.468284027@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Linux Kernel Functional Testing Tested-by: Shuah Khan Tested-by: Bagas Sanjaya Tested-by: Guenter Roeck Tested-by: Ron Economos Tested-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

Linux 5.15.58

2022-07-29T15:25:34Z

Link: https://lore.kernel.org/r/20220727161026.977588183@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya Tested-by: Jon Hunter Tested-by: Shuah Khan Link: https://lore.kernel.org/r/20220728133327.660846209@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Guenter Roeck Tested-by: Ron Economos Tested-by: Bagas Sanjaya Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

Linux 5.15.57

2022-07-23T10:54:14Z

Link: https://lore.kernel.org/r/20220722091133.320803732@linuxfoundation.org Tested-by: Bagas Sanjaya Tested-by: Florian Fainelli Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Tested-by: Ron Economos Tested-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman