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

Linux 5.19.6

2022-08-31T15:18:21Z

Link: https://lore.kernel.org/r/20220829105808.828227973@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Ron Economos Tested-by: Shuah Khan Tested-by: Zan Aziz Tested-by: Guenter Roeck Tested-by: Ronald Warsow Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Bagas Sanjaya Tested-by: Fenil Jain Tested-by: Rudi Heitbaum Tested-by: Justin M. Forbes Tested-by: Jiri Slaby Signed-off-by: Greg Kroah-Hartman

Linux 5.19.5

2022-08-29T09:18:05Z

Signed-off-by: Greg Kroah-Hartman

Linux 5.19.4

2022-08-25T09:45:54Z

Link: https://lore.kernel.org/r/20220823080118.128342613@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Justin M. Forbes Tested-by: Shuah Khan Tested-by: Rudi Heitbaum Tested-by: Ron Economos Link: https://lore.kernel.org/r/20220824065936.861377531@linuxfoundation.org Tested-by: Ron Economos Tested-by: Guenter Roeck Tested-by: Rudi Heitbaum 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:45:37Z

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

2022-08-21T13:20:09Z

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

Linux 5.19.2

2022-08-17T13:16:21Z

Link: https://lore.kernel.org/r/20220815180439.416659447@linuxfoundation.org Tested-by: Shuah Khan Tested-by: Ronald Warsow Tested-by: Bagas Sanjaya Tested-by: Ron Economos Link: https://lore.kernel.org/r/20220816124610.393032991@linuxfoundation.org Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Guenter Roeck Tested-by: Jiri Slaby Tested-by: Justin M. Forbes Signed-off-by: Greg Kroah-Hartman

io_uring: move to separate directory

2022-08-17T13:14:20Z

[ Upstream commit ed29b0b4fd835b058ddd151c49d021e28d631ee6 ] In preparation for splitting io_uring up a bit, move it into its own top level directory. It didn't really belong in fs/ anyway, as it's not a file system only API. This adds io_uring/ and moves the core files in there, and updates the MAINTAINERS file for the new location. Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin

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

2022-08-17T13:13:39Z

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

2022-08-11T11:22:05Z

Link: https://lore.kernel.org/r/20220809175513.345597655@linuxfoundation.org Tested-by: Ronald Warsow Tested-by: Florian Fainelli Tested-by: Zan Aziz Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Linux Kernel Functional Testing Tested-by: Bagas Sanjaya Tested-by: Fenil Jain Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Rudi Heitbaum Signed-off-by: Greg Kroah-Hartman

Linux 5.19

2022-07-31T21:03:01Z