user/sven/linux.git, branch v5.18.9

Linux 5.18.9

2022-07-02T14:44:56Z

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

io_uring: fix not locked access to fixed buf table

2022-07-02T14:44:55Z

commit 05b538c1765f8d14a71ccf5f85258dcbeaf189f7 upstream. We can look inside the fixed buffer table only while holding ->uring_lock, however in some cases we don't do the right async prep for IORING_OP_{WRITE,READ}_FIXED ending up with NULL req->imu forcing making an io-wq worker to try to resolve the fixed buffer without proper locking. Move req->imu setup into early req init paths, i.e. io_prep_rw(), which is called unconditionally for rw requests and under uring_lock. Fixes: 634d00df5e1cf ("io_uring: add full-fledged dynamic buffers support") Signed-off-by: Pavel Begunkov Signed-off-by: Greg Kroah-Hartman

powerpc/ftrace: Remove ftrace init tramp once kernel init is complete

2022-07-02T14:44:55Z

commit 84ade0a6655bee803d176525ef457175cbf4df22 upstream. Stop using the ftrace trampoline for init section once kernel init is complete. Fixes: 67361cf8071286 ("powerpc/ftrace: Handle large kernel configs") Cc: stable@vger.kernel.org # v4.20+ Signed-off-by: Naveen N. Rao Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220516071422.463738-1-naveen.n.rao@linux.vnet.ibm.com Signed-off-by: Greg Kroah-Hartman

hinic: Replace memcpy() with direct assignment

2022-07-02T14:44:55Z

commit 1e70212e031528918066a631c9fdccda93a1ffaa upstream. Under CONFIG_FORTIFY_SOURCE=y and CONFIG_UBSAN_BOUNDS=y, Clang is bugged here for calculating the size of the destination buffer (0x10 instead of 0x14). This copy is a fixed size (sizeof(struct fw_section_info_st)), with the source and dest being struct fw_section_info_st, so the memcpy should be safe, assuming the index is within bounds, which is UBSAN_BOUNDS's responsibility to figure out. Avoid the whole thing and just do a direct assignment. This results in no change to the executable code. [This is a duplicate of commit 2c0ab32b73cf ("hinic: Replace memcpy() with direct assignment") which was applied to net-next.] Cc: Nick Desaulniers Cc: Tom Rix Cc: llvm@lists.linux.dev Link: https://github.com/ClangBuiltLinux/linux/issues/1592 Signed-off-by: Kees Cook Reviewed-by: Gustavo A. R. Silva Tested-by: Nathan Chancellor # build Link: https://lore.kernel.org/r/20220616052312.292861-1-keescook@chromium.org Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

bcache: memset on stack variables in bch_btree_check() and bch_sectors_dirty_init()

2022-07-02T14:44:55Z

commit 7d6b902ea0e02b2a25c480edf471cbaa4ebe6b3c upstream. The local variables check_state (in bch_btree_check()) and state (in bch_sectors_dirty_init()) should be fully filled by 0, because before allocating them on stack, they were dynamically allocated by kzalloc(). Signed-off-by: Coly Li Link: https://lore.kernel.org/r/20220527152818.27545-2-colyli@suse.de Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman

clocksource/drivers/ixp4xx: Drop boardfile probe path

2022-07-02T14:44:55Z

commit 41929c9f628b9990d33a200c54bb0c919e089aa8 upstream. The boardfiles for IXP4xx have been deleted. Delete all the quirks and code dealing with that boot path and rely solely on device tree boot. Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20220406205505.2332821-1-linus.walleij@linaro.org Signed-off-by: Daniel Lezcano Signed-off-by: Greg Kroah-Hartman

tick/nohz: unexport __init-annotated tick_nohz_full_setup()

2022-07-02T14:44:55Z

commit 2390095113e98fc52fffe35c5206d30d9efe3f78 upstream. EXPORT_SYMBOL and __init is a bad combination because the .init.text section is freed up after the initialization. Hence, modules cannot use symbols annotated __init. The access to a freed symbol may end up with kernel panic. modpost used to detect it, but it had been broken for a decade. Commit 28438794aba4 ("modpost: fix section mismatch check for exported init/exit sections") fixed it so modpost started to warn it again, then this showed up: MODPOST vmlinux.symvers WARNING: modpost: vmlinux.o(___ksymtab_gpl+tick_nohz_full_setup+0x0): Section mismatch in reference from the variable __ksymtab_tick_nohz_full_setup to the function .init.text:tick_nohz_full_setup() The symbol tick_nohz_full_setup is exported and annotated __init Fix this by removing the __init annotation of tick_nohz_full_setup or drop the export. Drop the export because tick_nohz_full_setup() is only called from the built-in code in kernel/sched/isolation.c. Fixes: ae9e557b5be2 ("time: Export tick start/stop functions for rcutorture") Reported-by: Linus Torvalds Signed-off-by: Masahiro Yamada Tested-by: Paul E. McKenney Signed-off-by: Linus Torvalds Cc: Thomas Backlund Signed-off-by: Greg Kroah-Hartman

Linux 5.18.8

2022-06-29T07:04:44Z

Link: https://lore.kernel.org/r/20220627111944.553492442@linuxfoundation.org Tested-by: Jon Hunter Tested-by: Fenil Jain Tested-by: Ronald Warsow Tested-by: Rudi Heitbaum Tested-by: Shuah Khan Tested-by: Ron Economos Tested-by: Guenter Roeck Tested-by: Justin M. Forbes Tested-by: Bagas Sanjaya Tested-by: Sudip Mukherjee Signed-off-by: Greg Kroah-Hartman

powerpc/pseries: wire up rng during setup_arch()

2022-06-29T07:04:44Z

commit e561e472a3d441753bd012333b057f48fef1045b upstream. The platform's RNG must be available before random_init() in order to be useful for initial seeding, which in turn means that it needs to be called from setup_arch(), rather than from an init call. Fortunately, each platform already has a setup_arch function pointer, which means it's easy to wire this up. This commit also removes some noisy log messages that don't add much. Fixes: a489043f4626 ("powerpc/pseries: Implement arch_get_random_long() based on H_RANDOM") Cc: stable@vger.kernel.org # v3.13+ Signed-off-by: Jason A. Donenfeld Reviewed-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20220611151015.548325-4-Jason@zx2c4.com Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman

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

2022-06-29T07:04:43Z

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