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

Linux 5.12.11

2021-06-16T10:05:17Z

Link: https://lore.kernel.org/r/20210614102658.137943264@linuxfoundation.org Tested-by: Fox Chen Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Justin M. Forbes Tested-by: Jason Self Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

Makefile: LTO: have linker check -Wframe-larger-than

2021-06-16T10:05:03Z

[ Upstream commit 24845dcb170e16b3100bd49743687648c71387ae ] -Wframe-larger-than= requires stack frame information, which the frontend cannot provide. This diagnostic is emitted late during compilation once stack frame size is available. When building with LTO, the frontend simply lowers C to LLVM IR and does not have stack frame information, so it cannot emit this diagnostic. When the linker drives LTO, it restarts optimizations and lowers LLVM IR to object code. At that point, it has stack frame information but doesn't know to check for a specific max stack frame size. I consider this a bug in LLVM that we need to fix. There are some details we're working out related to LTO such as which value to use when there are multiple different values specified per TU, or how to propagate these to compiler synthesized routines properly, if at all. Until it's fixed, ensure we don't miss these. At that point we can wrap this in a compiler version guard or revert this based on the minimum support version of Clang. The error message is not generated during link: LTO vmlinux.o ld.lld: warning: stack size limit exceeded (8224) in foobarbaz Cc: Sami Tolvanen Reported-by: Candle Sun Suggested-by: Fangrui Song Signed-off-by: Nick Desaulniers Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20210312010942.1546679-1-ndesaulniers@google.com Signed-off-by: Sasha Levin

Linux 5.12.10

2021-06-10T11:41:49Z

Link: https://lore.kernel.org/r/20210608175945.476074951@linuxfoundation.org Tested-by: Fox Chen Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Tested-by: Jason Self Tested-by: Guenter Roeck Tested-by: Florian Fainelli Tested-by: Justin M. Forbes Signed-off-by: Greg Kroah-Hartman

Linux 5.12.9

2021-06-03T07:09:52Z

Link: https://lore.kernel.org/r/20210531130703.762129381@linuxfoundation.org Tested-by: Fox Chen Tested-by: Justin M. Forbes Tested-by: Florian Fainelli Tested-by: Linux Kernel Functional Testing Tested-by: Jason Self Tested-by: Rudi Heitbaum Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

Linux 5.12.8

2021-05-28T11:18:53Z

Link: https://lore.kernel.org/r/20210527151139.241267495@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Fox Chen Tested-by: Shuah Khan Tested-by: Florian Fainelli Reviewed-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing

Linux 5.12.7

2021-05-26T10:59:15Z

Link: https://lore.kernel.org/r/20210524152334.857620285@linuxfoundation.org Tested-by: Rudi Heitbaum Tested-by: Fox Chen Tested-by: Shuah Khan Tested-by: Florian Fainelli Tested-by: Jason Self Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Tested-by: Justin M. Forbes Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

Linux 5.12.6

2021-05-22T09:43:53Z

Link: https://lore.kernel.org/r/20210520092053.516042993@linuxfoundation.org Tested-by: Fox Chen Tested-by: Rudi Heitbaum Link: https://lore.kernel.org/r/20210520152254.218537944@linuxfoundation.org Tested-by: Shuah Khan Tested-by: Guenter Roeck Tested-by: Jason Self Tested-by: Linux Kernel Functional Testing Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Fox Chen Tested-by: Justin M. Forbes Signed-off-by: Greg Kroah-Hartman

Linux 5.12.5

2021-05-19T08:56:45Z

Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Fox Chen Tested-by: Jason Self Tested-by: Linux Kernel Functional Testing Tested-by: Rudi Heitbaum Link: https://lore.kernel.org/r/20210517140302.508966430@linuxfoundation.org Tested-by: Rudi Heitbaum Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Guenter Roeck Tested-by: Shuah Khan Tested-by: Justin M. Forbes Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20210518135831.445321364@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman

kbuild: generate Module.symvers only when vmlinux exists

2021-05-19T08:56:20Z

[ Upstream commit 69bc8d386aebbd91a6bb44b6d33f77c8dfa9ed8c ] The external module build shows the following warning if Module.symvers is missing in the kernel tree. WARNING: Symbol version dump "Module.symvers" is missing. Modules may not have dependencies or modversions. I think this is an important heads-up because the resulting modules may not work as expected. This happens when you did not build the entire kernel tree, for example, you might have prepared the minimal setups for external modules by 'make defconfig && make modules_preapre'. A problem is that 'make modules' creates Module.symvers even without vmlinux. In this case, that warning is suppressed since Module.symvers already exists in spite of its incomplete content. The incomplete (i.e. invalid) Module.symvers should not be created. This commit changes the second pass of modpost to dump symbols into modules-only.symvers. The final Module.symvers is created by concatenating vmlinux.symvers and modules-only.symvers if both exist. Module.symvers is supposed to collect symbols from both vmlinux and modules. It might be a bit confusing, and I am not quite sure if it is an official interface, but presumably it is difficult to rename it because some tools (e.g. kmod) parse it. Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

Linux 5.12.4

2021-05-14T08:53:07Z

Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Jason Self Tested-by: Fox Chen Reported-by: Linux Kernel Functional Testing Tested-by: Justin M. Forbes Link: https://lore.kernel.org/r/20210512144837.204217980@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman