This is the start of the stable review cycle for the 5.18.9 release. There are 6 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.9-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.18.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 5.18.9-rc1
Pavel Begunkov asml.silence@gmail.com io_uring: fix not locked access to fixed buf table
Naveen N. Rao naveen.n.rao@linux.vnet.ibm.com powerpc/ftrace: Remove ftrace init tramp once kernel init is complete
Kees Cook keescook@chromium.org hinic: Replace memcpy() with direct assignment
Coly Li colyli@suse.de bcache: memset on stack variables in bch_btree_check() and bch_sectors_dirty_init()
Linus Walleij linus.walleij@linaro.org clocksource/drivers/ixp4xx: Drop boardfile probe path
Masahiro Yamada masahiroy@kernel.org tick/nohz: unexport __init-annotated tick_nohz_full_setup()
-------------
Diffstat:
Makefile | 4 +-- arch/powerpc/include/asm/ftrace.h | 4 ++- arch/powerpc/kernel/trace/ftrace.c | 15 ++++++++-- arch/powerpc/mm/mem.c | 2 ++ drivers/clocksource/Kconfig | 2 +- drivers/clocksource/timer-ixp4xx.c | 25 ----------------- drivers/md/bcache/btree.c | 1 + drivers/md/bcache/writeback.c | 1 + drivers/net/ethernet/huawei/hinic/hinic_devlink.c | 4 +-- fs/io_uring.c | 34 ++++++++++++----------- include/linux/platform_data/timer-ixp4xx.h | 11 -------- kernel/time/tick-sched.c | 1 - 12 files changed, 41 insertions(+), 63 deletions(-)
From: Masahiro Yamada masahiroy@kernel.org
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 torvalds@linux-foundation.org Signed-off-by: Masahiro Yamada masahiroy@kernel.org Tested-by: Paul E. McKenney paulmck@kernel.org Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Cc: Thomas Backlund tmb@tmb.nu Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- kernel/time/tick-sched.c | 1 - 1 file changed, 1 deletion(-)
--- a/kernel/time/tick-sched.c +++ b/kernel/time/tick-sched.c @@ -526,7 +526,6 @@ void __init tick_nohz_full_setup(cpumask cpumask_copy(tick_nohz_full_mask, cpumask); tick_nohz_full_running = true; } -EXPORT_SYMBOL_GPL(tick_nohz_full_setup);
static int tick_nohz_cpu_down(unsigned int cpu) {
From: Linus Walleij linus.walleij@linaro.org
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 linus.walleij@linaro.org Link: https://lore.kernel.org/r/20220406205505.2332821-1-linus.walleij@linaro.org Signed-off-by: Daniel Lezcano daniel.lezcano@linaro.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/clocksource/Kconfig | 2 +- drivers/clocksource/timer-ixp4xx.c | 25 ------------------------- include/linux/platform_data/timer-ixp4xx.h | 11 ----------- 3 files changed, 1 insertion(+), 37 deletions(-) delete mode 100644 include/linux/platform_data/timer-ixp4xx.h
--- a/drivers/clocksource/Kconfig +++ b/drivers/clocksource/Kconfig @@ -80,7 +80,7 @@ config IXP4XX_TIMER bool "Intel XScale IXP4xx timer driver" if COMPILE_TEST depends on HAS_IOMEM select CLKSRC_MMIO - select TIMER_OF if OF + select TIMER_OF help Enables support for the Intel XScale IXP4xx SoC timer.
--- a/drivers/clocksource/timer-ixp4xx.c +++ b/drivers/clocksource/timer-ixp4xx.c @@ -19,8 +19,6 @@ #include <linux/of_address.h> #include <linux/of_irq.h> #include <linux/platform_device.h> -/* Goes away with OF conversion */ -#include <linux/platform_data/timer-ixp4xx.h>
/* * Constants to make it easy to access Timer Control/Status registers @@ -263,28 +261,6 @@ static struct platform_driver ixp4xx_tim }; builtin_platform_driver(ixp4xx_timer_driver);
-/** - * ixp4xx_timer_setup() - Timer setup function to be called from boardfiles - * @timerbase: physical base of timer block - * @timer_irq: Linux IRQ number for the timer - * @timer_freq: Fixed frequency of the timer - */ -void __init ixp4xx_timer_setup(resource_size_t timerbase, - int timer_irq, - unsigned int timer_freq) -{ - void __iomem *base; - - base = ioremap(timerbase, 0x100); - if (!base) { - pr_crit("IXP4xx: can't remap timer\n"); - return; - } - ixp4xx_timer_register(base, timer_irq, timer_freq); -} -EXPORT_SYMBOL_GPL(ixp4xx_timer_setup); - -#ifdef CONFIG_OF static __init int ixp4xx_of_timer_init(struct device_node *np) { void __iomem *base; @@ -315,4 +291,3 @@ out_unmap: return ret; } TIMER_OF_DECLARE(ixp4xx, "intel,ixp4xx-timer", ixp4xx_of_timer_init); -#endif --- a/include/linux/platform_data/timer-ixp4xx.h +++ /dev/null @@ -1,11 +0,0 @@ -/* SPDX-License-Identifier: GPL-2.0 */ -#ifndef __TIMER_IXP4XX_H -#define __TIMER_IXP4XX_H - -#include <linux/ioport.h> - -void __init ixp4xx_timer_setup(resource_size_t timerbase, - int timer_irq, - unsigned int timer_freq); - -#endif
From: Coly Li colyli@suse.de
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 colyli@suse.de Link: https://lore.kernel.org/r/20220527152818.27545-2-colyli@suse.de Signed-off-by: Jens Axboe axboe@kernel.dk Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/md/bcache/btree.c | 1 + drivers/md/bcache/writeback.c | 1 + 2 files changed, 2 insertions(+)
--- a/drivers/md/bcache/btree.c +++ b/drivers/md/bcache/btree.c @@ -2017,6 +2017,7 @@ int bch_btree_check(struct cache_set *c) if (c->root->level == 0) return 0;
+ memset(&check_state, 0, sizeof(struct btree_check_state)); check_state.c = c; check_state.total_threads = bch_btree_chkthread_nr(); check_state.key_idx = 0; --- a/drivers/md/bcache/writeback.c +++ b/drivers/md/bcache/writeback.c @@ -950,6 +950,7 @@ void bch_sectors_dirty_init(struct bcach return; }
+ memset(&state, 0, sizeof(struct bch_dirty_init_state)); state.c = c; state.d = d; state.total_threads = bch_btre_dirty_init_thread_nr();
From: Kees Cook keescook@chromium.org
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 ndesaulniers@google.com Cc: Tom Rix trix@redhat.com Cc: llvm@lists.linux.dev Link: https://github.com/ClangBuiltLinux/linux/issues/1592 Signed-off-by: Kees Cook keescook@chromium.org Reviewed-by: Gustavo A. R. Silva gustavoars@kernel.org Tested-by: Nathan Chancellor nathan@kernel.org # build Link: https://lore.kernel.org/r/20220616052312.292861-1-keescook@chromium.org Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/net/ethernet/huawei/hinic/hinic_devlink.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
--- a/drivers/net/ethernet/huawei/hinic/hinic_devlink.c +++ b/drivers/net/ethernet/huawei/hinic/hinic_devlink.c @@ -43,9 +43,7 @@ static bool check_image_valid(struct hin
for (i = 0; i < fw_image->fw_info.fw_section_cnt; i++) { len += fw_image->fw_section_info[i].fw_section_len; - memcpy(&host_image->image_section_info[i], - &fw_image->fw_section_info[i], - sizeof(struct fw_section_info_st)); + host_image->image_section_info[i] = fw_image->fw_section_info[i]; }
if (len != fw_image->fw_len ||
From: Naveen N. Rao naveen.n.rao@linux.vnet.ibm.com
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 naveen.n.rao@linux.vnet.ibm.com Signed-off-by: Michael Ellerman mpe@ellerman.id.au Link: https://lore.kernel.org/r/20220516071422.463738-1-naveen.n.rao@linux.vnet.ib... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- arch/powerpc/include/asm/ftrace.h | 4 +++- arch/powerpc/kernel/trace/ftrace.c | 15 ++++++++++++--- arch/powerpc/mm/mem.c | 2 ++ 3 files changed, 17 insertions(+), 4 deletions(-)
--- a/arch/powerpc/include/asm/ftrace.h +++ b/arch/powerpc/include/asm/ftrace.h @@ -86,7 +86,7 @@ static inline bool arch_syscall_match_sy #endif /* PPC64_ELF_ABI_v1 */ #endif /* CONFIG_FTRACE_SYSCALLS */
-#ifdef CONFIG_PPC64 +#if defined(CONFIG_PPC64) && defined(CONFIG_FUNCTION_TRACER) #include <asm/paca.h>
static inline void this_cpu_disable_ftrace(void) @@ -110,11 +110,13 @@ static inline u8 this_cpu_get_ftrace_ena return get_paca()->ftrace_enabled; }
+void ftrace_free_init_tramp(void); #else /* CONFIG_PPC64 */ static inline void this_cpu_disable_ftrace(void) { } static inline void this_cpu_enable_ftrace(void) { } static inline void this_cpu_set_ftrace_enabled(u8 ftrace_enabled) { } static inline u8 this_cpu_get_ftrace_enabled(void) { return 1; } +static inline void ftrace_free_init_tramp(void) { } #endif /* CONFIG_PPC64 */ #endif /* !__ASSEMBLY__ */
--- a/arch/powerpc/kernel/trace/ftrace.c +++ b/arch/powerpc/kernel/trace/ftrace.c @@ -306,9 +306,7 @@ static int setup_mcount_compiler_tramp(u
/* Is this a known long jump tramp? */ for (i = 0; i < NUM_FTRACE_TRAMPS; i++) - if (!ftrace_tramps[i]) - break; - else if (ftrace_tramps[i] == tramp) + if (ftrace_tramps[i] == tramp) return 0;
/* Is this a known plt tramp? */ @@ -863,6 +861,17 @@ void arch_ftrace_update_code(int command
extern unsigned int ftrace_tramp_text[], ftrace_tramp_init[];
+void ftrace_free_init_tramp(void) +{ + int i; + + for (i = 0; i < NUM_FTRACE_TRAMPS && ftrace_tramps[i]; i++) + if (ftrace_tramps[i] == (unsigned long)ftrace_tramp_init) { + ftrace_tramps[i] = 0; + return; + } +} + int __init ftrace_dyn_arch_init(void) { int i; --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -22,6 +22,7 @@ #include <asm/kasan.h> #include <asm/svm.h> #include <asm/mmzone.h> +#include <asm/ftrace.h>
#include <mm/mmu_decl.h>
@@ -312,6 +313,7 @@ void free_initmem(void) ppc_md.progress = ppc_printk_progress; mark_initmem_nx(); free_initmem_default(POISON_FREE_INITMEM); + ftrace_free_init_tramp(); }
/*
From: Pavel Begunkov asml.silence@gmail.com
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 asml.silence@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- fs/io_uring.c | 34 ++++++++++++++++++---------------- 1 file changed, 18 insertions(+), 16 deletions(-)
--- a/fs/io_uring.c +++ b/fs/io_uring.c @@ -3187,6 +3187,21 @@ static int io_prep_rw(struct io_kiocb *r int ret;
kiocb->ki_pos = READ_ONCE(sqe->off); + /* used for fixed read/write too - just read unconditionally */ + req->buf_index = READ_ONCE(sqe->buf_index); + req->imu = NULL; + + if (req->opcode == IORING_OP_READ_FIXED || + req->opcode == IORING_OP_WRITE_FIXED) { + struct io_ring_ctx *ctx = req->ctx; + u16 index; + + if (unlikely(req->buf_index >= ctx->nr_user_bufs)) + return -EFAULT; + index = array_index_nospec(req->buf_index, ctx->nr_user_bufs); + req->imu = ctx->user_bufs[index]; + io_req_set_rsrc_node(req, ctx, 0); + }
ioprio = READ_ONCE(sqe->ioprio); if (ioprio) { @@ -3199,11 +3214,9 @@ static int io_prep_rw(struct io_kiocb *r kiocb->ki_ioprio = get_current_ioprio(); }
- req->imu = NULL; req->rw.addr = READ_ONCE(sqe->addr); req->rw.len = READ_ONCE(sqe->len); req->rw.flags = READ_ONCE(sqe->rw_flags); - req->buf_index = READ_ONCE(sqe->buf_index); return 0; }
@@ -3335,20 +3348,9 @@ static int __io_import_fixed(struct io_k static int io_import_fixed(struct io_kiocb *req, int rw, struct iov_iter *iter, unsigned int issue_flags) { - struct io_mapped_ubuf *imu = req->imu; - u16 index, buf_index = req->buf_index; - - if (likely(!imu)) { - struct io_ring_ctx *ctx = req->ctx; - - if (unlikely(buf_index >= ctx->nr_user_bufs)) - return -EFAULT; - io_req_set_rsrc_node(req, ctx, issue_flags); - index = array_index_nospec(buf_index, ctx->nr_user_bufs); - imu = READ_ONCE(ctx->user_bufs[index]); - req->imu = imu; - } - return __io_import_fixed(req, rw, iter, imu); + if (WARN_ON_ONCE(!req->imu)) + return -EFAULT; + return __io_import_fixed(req, rw, iter, req->imu); }
static void io_ring_submit_unlock(struct io_ring_ctx *ctx, bool needs_lock)
On Thu, 30 Jun 2022 15:47:26 +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.18.9 release. There are 6 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.9-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.18.y and the diffstat can be found below.
thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.18: 10 builds: 10 pass, 0 fail 28 boots: 28 pass, 0 fail 130 tests: 130 pass, 0 fail
Linux version: 5.18.9-rc1-g2c9a64b3a872 Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000, tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000, tegra20-ventana, tegra210-p2371-2180, tegra210-p3450-0000, tegra30-cardhu-a04
Tested-by: Jon Hunter jonathanh@nvidia.com
Jon
On Thu, Jun 30, 2022 at 9:17 AM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 5.18.9 release. There are 6 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.9-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.18.y and the diffstat can be found below.
thanks,
greg k-h
Hi Greg,
Compiled and booted on my test system Lenovo P50s: Intel Core i7 No emergency and critical messages in the dmesg
./perf bench sched all # Running sched/messaging benchmark... # 20 sender and receiver processes per group # 10 groups == 400 processes run
Total time: 0.427 [sec]
# Running sched/pipe benchmark... # Executed 1000000 pipe operations between two processes
Total time: 10.046 [sec]
10.046035 usecs/op 99541 ops/sec
Tested-by: Zan Aziz zanaziz313@gmail.com
Thanks -Zan
On 6/30/22 7:47 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.18.9 release. There are 6 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.9-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.18.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan skhan@linuxfoundation.org
thanks, -- Shuah
On 6/30/2022 6:47 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.18.9 release. There are 6 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.9-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.18.y and the diffstat can be found below.
thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels:
Tested-by: Florian Fainelli f.fainelli@gmail.com
On Thu, Jun 30, 2022 at 03:47:26PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.18.9 release. There are 6 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000. Anything received after that time might be too late.
Build results: total: 154 pass: 154 fail: 0 Qemu test results: total: 489 pass: 489 fail: 0
Tested-by: Guenter Roeck linux@roeck-us.net
Guenter
On 6/30/22 6:47 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.18.9 release. There are 6 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.9-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.18.y and the diffstat can be found below.
thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Tested-by: Ron Economos re@w6rz.net
On Thu, 30 Jun 2022 at 19:26, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 5.18.9 release. There are 6 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.9-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.18.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing lkft@linaro.org
## Build * kernel: 5.18.9-rc1 * git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc * git branch: linux-5.18.y * git commit: 2c9a64b3a872fb2818d217509b16e61ba54c365e * git describe: v5.18.8-7-g2c9a64b3a872 * test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.18.y/build/v5.18....
## Test Regressions (compared to v5.18.8) No test regressions found.
## Metric Regressions (compared to v5.18.8) No metric regressions found.
## Test Fixes (compared to v5.18.8) No test fixes found.
## Metric Fixes (compared to v5.18.8) No metric fixes found.
## Test result summary total: 120950, pass: 109794, fail: 546, skip: 9999, xfail: 611
## Build Summary * arc: 10 total, 10 passed, 0 failed * arm: 307 total, 307 passed, 0 failed * arm64: 62 total, 62 passed, 0 failed * i386: 52 total, 49 passed, 3 failed * mips: 48 total, 48 passed, 0 failed * parisc: 12 total, 12 passed, 0 failed * powerpc: 60 total, 54 passed, 6 failed * riscv: 27 total, 22 passed, 5 failed * s390: 18 total, 18 passed, 0 failed * sh: 24 total, 24 passed, 0 failed * sparc: 12 total, 12 passed, 0 failed * x86_64: 56 total, 54 passed, 2 failed
## Test suites summary * fwts * igt-gpu-tools * kselftest-android * kselftest-breakpoints * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-drivers-dma-buf * kselftest-efivarfs * kselftest-filesystems * kselftest-filesystems-binderfs * kselftest-firmware * kselftest-fpu * kselftest-gpio * kselftest-ipc * kselftest-ir * kselftest-kcmp * kselftest-lib * kselftest-membarrier * kselftest-netfilter * kselftest-nsfs * kselftest-openat2 * kselftest-pid_namespace * kselftest-pidfd * kselftest-proc * kselftest-pstore * kselftest-rseq * kselftest-rtc * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-splice * kselftest-static_keys * kselftest-sync * kselftest-sysctl * kselftest-tc-testing * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-vm * kselftest-zram * kunit * kvm-unit-tests * libgpiod * libhugetlbfs * log-parser-boot * log-parser-test * ltp-cap_bounds * ltp-commands * ltp-containers * ltp-controllers * ltp-cpuhotplug * ltp-crypto * ltp-cve * ltp-dio * ltp-fcntl-locktests * ltp-filecaps * ltp-fs * ltp-fs_bind * ltp-fs_perms_simple * ltp-fsx * ltp-hugetlb * ltp-io * ltp-ipc * ltp-math * ltp-mm * ltp-nptl * ltp-open-posix-tests * ltp-pty * ltp-sched * ltp-securebits * ltp-smoke * ltp-syscalls * ltp-tracing * network-basic-tests * packetdrill * perf * perf/Zstd-perf.data-compression * rcutorture * ssuite * v4l2-compliance * vdso
-- Linaro LKFT https://lkft.linaro.org
On Thu, Jun 30, 2022 at 03:47:26PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.18.9 release. There are 6 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Successfully cross-compiled for arm64 (bcm2711_defconfig, GCC 12.1.0) and powerpc (ps3_defconfig, GCC 12.1.0).
I get a warning on cifs:
CC [M] fs/cifs/connect.o CC drivers/tty/tty_baudrate.o CC drivers/tty/tty_jobctrl.o fs/cifs/connect.c: In function 'is_path_remote': fs/cifs/connect.c:3426:14: warning: unused variable 'nodfs' [-Wunused-variable] 3426 | bool nodfs = cifs_sb->mnt_cifs_flags & CIFS_MOUNT_NO_DFS; | ^~~~~
The culprit is commit 2340f1adf9fbb3 ("cifs: don't call cifs_dfs_query_info_nonascii_quirk() if nodfs was set") (upstream commit 421ef3d56513b2).
Tested-by: Bagas Sanjaya bagasdotme@gmail.com
On Fri, Jul 01, 2022 at 02:59:10PM +0700, Bagas Sanjaya wrote:
On Thu, Jun 30, 2022 at 03:47:26PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.18.9 release. There are 6 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Successfully cross-compiled for arm64 (bcm2711_defconfig, GCC 12.1.0) and powerpc (ps3_defconfig, GCC 12.1.0).
I get a warning on cifs:
CC [M] fs/cifs/connect.o CC drivers/tty/tty_baudrate.o CC drivers/tty/tty_jobctrl.o fs/cifs/connect.c: In function 'is_path_remote': fs/cifs/connect.c:3426:14: warning: unused variable 'nodfs' [-Wunused-variable] 3426 | bool nodfs = cifs_sb->mnt_cifs_flags & CIFS_MOUNT_NO_DFS; | ^~~~~
The culprit is commit 2340f1adf9fbb3 ("cifs: don't call cifs_dfs_query_info_nonascii_quirk() if nodfs was set") (upstream commit 421ef3d56513b2).
Again, gcc-12 is going to have problems with stable releases until Linus's tree is fixed up entirely. Once that happens, then I will take backports to stable kernels to get them to build properly.
But until then, no need to report anything here, as there's nothing I can do.
thanks,
greg k-h
On 7/1/22 15:24, Greg Kroah-Hartman wrote:
Again, gcc-12 is going to have problems with stable releases until Linus's tree is fixed up entirely. Once that happens, then I will take backports to stable kernels to get them to build properly.
OK.
I also tried building the mainline (with ppc64_defconfig), no warnings reported.
Thanks.
On Fri, Jul 01, 2022 at 10:24:10AM +0200, Greg Kroah-Hartman wrote:
On Fri, Jul 01, 2022 at 02:59:10PM +0700, Bagas Sanjaya wrote:
On Thu, Jun 30, 2022 at 03:47:26PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.18.9 release. There are 6 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Successfully cross-compiled for arm64 (bcm2711_defconfig, GCC 12.1.0) and powerpc (ps3_defconfig, GCC 12.1.0).
I get a warning on cifs:
CC [M] fs/cifs/connect.o CC drivers/tty/tty_baudrate.o CC drivers/tty/tty_jobctrl.o fs/cifs/connect.c: In function 'is_path_remote': fs/cifs/connect.c:3426:14: warning: unused variable 'nodfs' [-Wunused-variable] 3426 | bool nodfs = cifs_sb->mnt_cifs_flags & CIFS_MOUNT_NO_DFS; | ^~~~~
The culprit is commit 2340f1adf9fbb3 ("cifs: don't call cifs_dfs_query_info_nonascii_quirk() if nodfs was set") (upstream commit 421ef3d56513b2).
Again, gcc-12 is going to have problems with stable releases until Linus's tree is fixed up entirely. Once that happens, then I will take backports to stable kernels to get them to build properly.
I have not tested, but this should be fixed by this one:
93ed91c020aa ("cifs: fix minor compile warning")
-- Regards Sudip
On Fri, Jul 01, 2022 at 11:31:27AM +0100, Sudip Mukherjee wrote:
On Fri, Jul 01, 2022 at 10:24:10AM +0200, Greg Kroah-Hartman wrote:
On Fri, Jul 01, 2022 at 02:59:10PM +0700, Bagas Sanjaya wrote:
On Thu, Jun 30, 2022 at 03:47:26PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.18.9 release. There are 6 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Successfully cross-compiled for arm64 (bcm2711_defconfig, GCC 12.1.0) and powerpc (ps3_defconfig, GCC 12.1.0).
I get a warning on cifs:
CC [M] fs/cifs/connect.o CC drivers/tty/tty_baudrate.o CC drivers/tty/tty_jobctrl.o fs/cifs/connect.c: In function 'is_path_remote': fs/cifs/connect.c:3426:14: warning: unused variable 'nodfs' [-Wunused-variable] 3426 | bool nodfs = cifs_sb->mnt_cifs_flags & CIFS_MOUNT_NO_DFS; | ^~~~~
The culprit is commit 2340f1adf9fbb3 ("cifs: don't call cifs_dfs_query_info_nonascii_quirk() if nodfs was set") (upstream commit 421ef3d56513b2).
Again, gcc-12 is going to have problems with stable releases until Linus's tree is fixed up entirely. Once that happens, then I will take backports to stable kernels to get them to build properly.
I have not tested, but this should be fixed by this one:
93ed91c020aa ("cifs: fix minor compile warning")
Thanks, now queued up.
greg k-h
Hi Greg,
On Thu, Jun 30, 2022 at 03:47:26PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.18.9 release. There are 6 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000. Anything received after that time might be too late.
Build test (gcc version 12.1.1 20220627): mips: 59 configs -> no failure arm: 99 configs -> no failure arm64: 3 configs -> no failure x86_64: 4 configs -> no failure alpha allmodconfig -> no failure csky allmodconfig -> no failure powerpc allmodconfig -> no failure riscv allmodconfig -> no failure s390 allmodconfig -> no failure xtensa allmodconfig -> no failure
Boot test: x86_64: Booted on my test laptop. No regression. x86_64: Booted on qemu. No regression. [1] arm64: Booted on rpi4b (4GB model). No regression. [2] mips: Booted on ci20 board. No regression. [3]
[1]. https://openqa.qa.codethink.co.uk/tests/1431 [2]. https://openqa.qa.codethink.co.uk/tests/1438 [3]. https://openqa.qa.codethink.co.uk/tests/1440
Tested-by: Sudip Mukherjee sudip.mukherjee@codethink.co.uk
-- Regards Sudip
On Thu, Jun 30, 2022 at 03:47:26PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.18.9 release. There are 6 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000. Anything received after that time might be too late.
Hi Greg,
5.18.8-rc1 tested.
Run tested on: - Intel Tiger Lake x86_64 (nuc11 i7-1165G7)
In addition - build tested for: - Allwinner A64 - Allwinner H3 - Allwinner H5 - Allwinner H6 - NXP iMX6 - NXP iMX8 - Qualcomm Dragonboard - Rockchip RK3288 - Rockchip RK3328 - Rockchip RK3399pro - Samsung Exynos
Tested-by: Rudi Heitbaum rudi@heitbaum.com -- Rudi
On Thu, Jun 30, 2022 at 03:47:26PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.18.9 release. There are 6 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000. Anything received after that time might be too late.
Hi Greg,
resend:
5.18.9-rc1 tested.
Run tested on: - Intel Tiger Lake x86_64 (nuc11 i7-1165G7)
In addition - build tested for: - Allwinner A64 - Allwinner H3 - Allwinner H5 - Allwinner H6 - NXP iMX6 - NXP iMX8 - Qualcomm Dragonboard - Rockchip RK3288 - Rockchip RK3328 - Rockchip RK3399pro - Samsung Exynos
Tested-by: Rudi Heitbaum rudi@heitbaum.com -- Rudi
On Thu, Jun 30, 2022 at 03:47:26PM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.18.9 release. There are 6 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Sat, 02 Jul 2022 13:32:22 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.9-rc1.... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.18.y and the diffstat can be found below.
thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, armv7, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.
Tested-by: Justin M. Forbes jforbes@fedoraproject.org
linux-stable-mirror@lists.linaro.org
-
Bagas Sanjaya -
Florian Fainelli -
Greg Kroah-Hartman -
Guenter Roeck -
Jon Hunter -
Justin Forbes -
Naresh Kamboju -
Ron Economos -
Rudi Heitbaum -
Shuah Khan -
Sudip Mukherjee -
Zan Aziz