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

Linux 5.15.52

2022-07-02T14:41:19Z

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

Linux 5.15.51

2022-06-29T07:03:32Z

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

kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS (2nd attempt)

2022-06-29T07:03:32Z

commit 53632ba87d9f302a8d97a11ec2f4f4eec7bb75ea upstream. If CONFIG_TRIM_UNUSED_KSYMS is enabled and the kernel is built from a pristine state, the vmlinux is linked twice. Commit 3fdc7d3fe4c0 ("kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS") explains why this happens, but it did not fix the issue at all. Now I realized I had applied a wrong patch. In v1 patch [1], the autoksyms_recursive target correctly recurses to "$(MAKE) -f $(srctree)/Makefile autoksyms_recursive". In v2 patch [2], I accidentally dropped the diff line, and it recurses to "$(MAKE) -f $(srctree)/Makefile vmlinux". Restore the code I intended in v1. [1]: https://lore.kernel.org/linux-kbuild/1521045861-22418-8-git-send-email-yamada.masahiro@socionext.com/ [2]: https://lore.kernel.org/linux-kbuild/1521166725-24157-8-git-send-email-yamada.masahiro@socionext.com/ Fixes: 3fdc7d3fe4c0 ("kbuild: link vmlinux only once for CONFIG_TRIM_UNUSED_KSYMS") Signed-off-by: Masahiro Yamada Tested-by: Sami Tolvanen Reviewed-by: Nick Desaulniers Signed-off-by: Greg Kroah-Hartman

Linux 5.15.50

2022-06-25T13:18:40Z

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

Linux 5.15.49

2022-06-22T12:22:05Z

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

gcc-12: disable '-Wdangling-pointer' warning for now

2022-06-22T12:21:58Z

[ Upstream commit 49beadbd47c270a00754c107a837b4f29df4c822 ] While the concept of checking for dangling pointers to local variables at function exit is really interesting, the gcc-12 implementation is not compatible with reality, and results in false positives. For example, gcc sees us putting things on a local list head allocated on the stack, which involves exactly those kinds of pointers to the local stack entry: In function ‘__list_add’, inlined from ‘list_add_tail’ at include/linux/list.h:102:2, inlined from ‘rebuild_snap_realms’ at fs/ceph/snap.c:434:2: include/linux/list.h:74:19: warning: storing the address of local variable ‘realm_queue’ in ‘*&realm_27(D)->rebuild_item.prev’ [-Wdangling-pointer=] 74 | new->prev = prev; | ~~~~~~~~~~^~~~~~ But then gcc - understandably - doesn't really understand the big picture how the doubly linked list works, so doesn't see how we then end up emptying said list head in a loop and the pointer we added has been removed. Gcc also complains about us (intentionally) using this as a way to store a kind of fake stack trace, eg drivers/acpi/acpica/utdebug.c:40:38: warning: storing the address of local variable ‘current_sp’ in ‘acpi_gbl_entry_stack_pointer’ [-Wdangling-pointer=] 40 | acpi_gbl_entry_stack_pointer = ¤t_sp; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~ which is entirely reasonable from a compiler standpoint, and we may want to change those kinds of patterns, but not not. So this is one of those "it would be lovely if the compiler were to complain about us leaving dangling pointers to the stack", but not this way. Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin

Linux 5.15.48

2022-06-16T11:30:35Z

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

Linux 5.15.47

2022-06-14T16:36:28Z

Link: https://lore.kernel.org/r/20220613094922.843438024@linuxfoundation.org Tested-by: Fox Chen Tested-by: Bagas Sanjaya Link: https://lore.kernel.org/r/20220613181847.216528857@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Fox Chen Tested-by: Sudip Mukherjee Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

Linux 5.15.46

2022-06-09T08:23:32Z

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

Linux 5.15.45

2022-06-06T06:43:42Z

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