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

Linux 5.10.185

2023-06-21T13:45:41Z

Link: https://lore.kernel.org/r/20230619102138.279161276@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Salvatore Bonaccorso Tested-by: Chris Paterson (CIP) Tested-by: Jon Hunter Tested-by: Sudip Mukherjee Tested-by: Linux Kernel Functional Testing Tested-by: Allen Pais Tested-by: Shuah Khan Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

Linux 5.10.184

2023-06-14T09:10:02Z

Link: https://lore.kernel.org/r/20230612101658.437327280@linuxfoundation.org Tested-by: Chris Paterson (CIP) Tested-by: Shuah Khan Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Sudip Mukherjee Tested-by: Allen Pais Tested-by: Salvatore Bonaccorso Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

Linux 5.10.183

2023-06-09T08:30:19Z

Link: https://lore.kernel.org/r/20230607200900.915613242@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Chris Paterson (CIP) Tested-by: Linux Kernel Functional Testing Tested-by: Salvatore Bonaccorso Tested-by: Guenter Roeck Tested-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

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

2023-06-09T08:30:15Z

commit f7d63b50898172b9eb061b9e2daad61b428792d0 upstream. [ 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 Signed-off-by: Greg Kroah-Hartman

Linux 5.10.182

2023-06-05T07:07:04Z

Link: https://lore.kernel.org/r/20230601131933.727832920@linuxfoundation.org Tested-by: Florian Fainelli Tested-by: Shuah Khan Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Salvatore Bonaccorso Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

Linux 5.10.181

2023-05-30T11:57:59Z

Link: https://lore.kernel.org/r/20230528190843.514829708@linuxfoundation.org Tested-by: Guenter Roeck Tested-by: Linux Kernel Functional Testing Tested-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

Linux 5.10.180

2023-05-17T09:48:20Z

Link: https://lore.kernel.org/r/20230515161736.775969473@linuxfoundation.org Tested-by: Chris Paterson (CIP) Tested-by: Shuah Khan Tested-by: Sudip Mukherjee Tested-by: Guenter Roeck Tested-by: Jon Hunter Signed-off-by: Greg Kroah-Hartman

Linux 5.10.179

2023-04-26T09:27:43Z

Link: https://lore.kernel.org/r/20230424131127.653885914@linuxfoundation.org Tested-by: Salvatore Bonaccorso Tested-by: Guenter Roeck Tested-by: Jon Hunter Tested-by: Linux Kernel Functional Testing Tested-by: Chris Paterson (CIP) Tested-by: Florian Fainelli Tested-by: Shuah Khan Signed-off-by: Greg Kroah-Hartman

Linux 5.10.178

2023-04-20T10:10:29Z

Link: https://lore.kernel.org/r/20230418120309.539243408@linuxfoundation.org Tested-by: Florian Fainelli Link: https://lore.kernel.org/r/20230419072207.996418578@linuxfoundation.org Tested-by: Chris Paterson (CIP) Tested-by: Jon Hunter Tested-by: Salvatore Bonaccorso Tested-by: Florian Fainelli Tested-by: Guenter Roeck Signed-off-by: Greg Kroah-Hartman

kbuild: check CONFIG_AS_IS_LLVM instead of LLVM_IAS

2023-04-20T10:10:28Z

commit 52cc02b910284d6bddba46cce402044ab775f314 upstream. LLVM_IAS is the user interface to set the -(no-)integrated-as flag, and it should be used only for that purpose. LLVM_IAS is checked in some places to determine the assembler type, but it is not precise. For example, $ make CC=gcc LLVM_IAS=1 ... will use the GNU assembler (i.e. binutils) since LLVM_IAS=1 is effective only when $(CC) is clang. Of course, 'CC=gcc LLVM_IAS=1' is an odd combination, but the build system can be more robust against such insane input. Commit ba64beb17493a ("kbuild: check the minimum assembler version in Kconfig") introduced CONFIG_AS_IS_GNU/LLVM, which is more precise because Kconfig checks the version string from the assembler in use. Signed-off-by: Masahiro Yamada Reviewed-by: Nick Desaulniers Reviewed-by: Nathan Chancellor [nathan: Backport to 5.10] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman