- Linux-stable-mirror - lists.linaro.org

FAILED: patch "[PATCH] selftests: mptcp: join: mark 'delete re-add signal' as" failed to apply to 6.12-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.12-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y git checkout FETCH_HEAD git cherry-pick -x c3496c052ac36ea98ec4f8e95ae6285a425a2457 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102627-enclosure-issue-a264@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From c3496c052ac36ea98ec4f8e95ae6285a425a2457 Mon Sep 17 00:00:00 2001 From: "Matthieu Baerts (NGI0)" <matttbe(a)kernel.org> Date: Mon, 20 Oct 2025 22:53:29 +0200 Subject: [PATCH] selftests: mptcp: join: mark 'delete re-add signal' as skipped if not supported The call to 'continue_if' was missing: it properly marks a subtest as 'skipped' if the attached condition is not valid. Without that, the test is wrongly marked as passed on older kernels. Fixes: b5e2fb832f48 ("selftests: mptcp: add explicit test case for remove/readd") Cc: stable(a)vger.kernel.org Reviewed-by: Geliang Tang <geliang(a)kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> Link: https://patch.msgid.link/20251020-net-mptcp-c-flag-late-add-addr-v1-4-82070… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/tools/testing/selftests/net/mptcp/mptcp_join.sh b/tools/testing/selftests/net/mptcp/mptcp_join.sh index d98f8f8905b9..b2a8c51a3969 100755 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh +++ b/tools/testing/selftests/net/mptcp/mptcp_join.sh @@ -4040,7 +4040,7 @@ endpoint_tests() # remove and re-add if reset_with_events "delete re-add signal" && - mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then + continue_if mptcp_lib_kallsyms_has "subflow_rebuild_header$"; then ip netns exec $ns1 sysctl -q net.mptcp.add_addr_timeout=0 pm_nl_set_limits $ns1 0 3 pm_nl_set_limits $ns2 3 3

1 week, 1 day

2
2
0 0

[PATCH] soc: qcom: gsbi: fix double disable caused by devm

by Haotian Zhang

In the commit referenced by the Fixes tag, devm_clk_get_enabled() was introduced to replace devm_clk_get() and clk_prepare_enable(). While the clk_disable_unprepare() call in the error path was correctly removed, the one in the remove function was overlooked, leading to a double disable issue. Remove the redundant clk_disable_unprepare() call from gsbi_remove() to fix this issue. Since all resources are now managed by devres and will be automatically released, the remove function serves no purpose and can be deleted entirely. Fixes: 489d7a8cc286 ("soc: qcom: use devm_clk_get_enabled() in gsbi_probe()") Signed-off-by: Haotian Zhang <vulab(a)iscas.ac.cn> --- drivers/soc/qcom/qcom_gsbi.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/drivers/soc/qcom/qcom_gsbi.c b/drivers/soc/qcom/qcom_gsbi.c index 8f1158e0c631..a25d1de592f0 100644 --- a/drivers/soc/qcom/qcom_gsbi.c +++ b/drivers/soc/qcom/qcom_gsbi.c @@ -212,13 +212,6 @@ static int gsbi_probe(struct platform_device *pdev) return of_platform_populate(node, NULL, NULL, &pdev->dev); } -static void gsbi_remove(struct platform_device *pdev) -{ - struct gsbi_info *gsbi = platform_get_drvdata(pdev); - - clk_disable_unprepare(gsbi->hclk); -} - static const struct of_device_id gsbi_dt_match[] = { { .compatible = "qcom,gsbi-v1.0.0", }, { }, @@ -232,7 +225,6 @@ static struct platform_driver gsbi_driver = { .of_match_table = gsbi_dt_match, }, .probe = gsbi_probe, - .remove = gsbi_remove, }; module_platform_driver(gsbi_driver); -- 2.25.1

1 week, 1 day

4
3
0 0

[PATCH 0/2] Kconfig fixes for QCOM clk drivers when targeting ARCH=arm

by Nathan Chancellor

Hi all, This series resolves two new Kconfig warnings that I see in my test framework from an ARM configuration getting bumped to 6.17 and enabling these configurations in the process. --- Nathan Chancellor (2): clk: qcom: Fix SM_VIDEOCC_6350 dependencies clk: qcom: Fix dependencies of QCS_{DISP,GPU,VIDEO}CC_615 drivers/clk/qcom/Kconfig | 4 ++++ 1 file changed, 4 insertions(+) --- base-commit: 30bf3ec8cb6b2d2e2f8715388395cbd27cbe4fc9 change-id: 20250930-clk-qcom-kconfig-fixes-arm-3611dec03c3e Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

1 week, 1 day

4
7
0 0

[PATCH v2] usb: renesas_usbhs: Fix synchronous external abort on unbind

by Claudiu

From: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> A synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is executed after the configuration sequence described above: modprobe usb_f_ecm modprobe libcomposite modprobe configfs cd /sys/kernel/config/usb_gadget mkdir -p g1 cd g1 echo "0x1d6b" > idVendor echo "0x0104" > idProduct mkdir -p strings/0x409 echo "0123456789" > strings/0x409/serialnumber echo "Renesas." > strings/0x409/manufacturer echo "Ethernet Gadget" > strings/0x409/product mkdir -p functions/ecm.usb0 mkdir -p configs/c.1 mkdir -p configs/c.1/strings/0x409 echo "ECM" > configs/c.1/strings/0x409/configuration if [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1 fi echo 11e20000.usb > UDC echo 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind The displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1 The issue occurs because usbhs_sys_function_pullup(), which accesses the IP registers, is executed after the USBHS clocks have been disabled. The problem is reproducible on the Renesas RZ/G3S SoC starting with the addition of module stop in the clock enable/disable APIs. With module stop functionality enabled, a bus error is expected if a master accesses a module whose clock has been stopped and module stop activated. Disable the IP clocks at the end of remove. Cc: stable(a)vger.kernel.org Fixes: f1407d5c6624 ("usb: renesas_usbhs: Add Renesas USBHS common code") Signed-off-by: Claudiu Beznea <claudiu.beznea.uj(a)bp.renesas.com> --- Changes in v2: - moved usbhsc_clk_put() before pm_runtime_disable() Patch was tested with continuous unbind/bind and the configuration sequence described above on the boards with the following device trees: - r8a774a1-hihope-rzg2m-ex.dts - r8a774b1-hihope-rzg2n-ex.dts - r8a774e1-hihope-rzg2h-ex.dts - r9a07g043u11-smarc.dts - r9a07g044c2-smarc.dts - r9a07g044l2-smarc.dts - r9a07g054l2-smarc.dts drivers/usb/renesas_usbhs/common.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/usb/renesas_usbhs/common.c b/drivers/usb/renesas_usbhs/common.c index 8f536f2c500f..dc2fec9168b7 100644 --- a/drivers/usb/renesas_usbhs/common.c +++ b/drivers/usb/renesas_usbhs/common.c @@ -813,18 +813,18 @@ static void usbhs_remove(struct platform_device *pdev) flush_delayed_work(&priv->notify_hotplug_work); - /* power off */ - if (!usbhs_get_dparam(priv, runtime_pwctrl)) - usbhsc_power_ctrl(priv, 0); - - pm_runtime_disable(&pdev->dev); - usbhs_platform_call(priv, hardware_exit, pdev); - usbhsc_clk_put(priv); reset_control_assert(priv->rsts); usbhs_mod_remove(priv); usbhs_fifo_remove(priv); usbhs_pipe_remove(priv); + + /* power off */ + if (!usbhs_get_dparam(priv, runtime_pwctrl)) + usbhsc_power_ctrl(priv, 0); + + usbhsc_clk_put(priv); + pm_runtime_disable(&pdev->dev); } static int usbhsc_suspend(struct device *dev) -- 2.43.0

1 week, 1 day

1
0
0 0

[REGRESSION] stable-rc/linux-5.10.y: (build) implicit declaration of function ‘of_get_cpu_hwid’; did you mean ‘...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.10.y: --- implicit declaration of function ‘of_get_cpu_hwid’; did you mean ‘of_get_cpu_node’? [-Werror=implicit-function-declaration] in arch/riscv/kernel/cpu.o (arch/riscv/kernel/cpu.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:aa2fc1f4fdbcaf13e029f04263806fde636d74fd - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 7288ed51fe2777d083b6cb13bd2d18f368fa425d Log excerpt: ===================================================== arch/riscv/kernel/cpu.c:24:33: error: implicit declaration of function ‘of_get_cpu_hwid’; did you mean ‘of_get_cpu_node’? [-Werror=implicit-function-declaration] 24 | *hart = (unsigned long) of_get_cpu_hwid(node, 0); | ^~~~~~~~~~~~~~~ | of_get_cpu_node AR init/built-in.a CC kernel/locking/mutex.o CC arch/riscv/mm/fault.o cc1: some warnings being treated as errors ===================================================== # Builds where the incident occurred: ## defconfig on (riscv): - compiler: gcc-12 - config: https://files.kernelci.org/kbuild-gcc-12-riscv-68ff66e51198e7d4c92ca056/.co… - dashboard: https://d.kernelci.org/build/maestro:68ff66e51198e7d4c92ca056 #kernelci issue maestro:aa2fc1f4fdbcaf13e029f04263806fde636d74fd Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

1 week, 1 day

1
0
0 0

[REGRESSION] stable-rc/linux-5.15.y: (build) unused variable ‘ext_end’ [-Wunused-variable] in arch/riscv/kernel...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.15.y: --- unused variable ‘ext_end’ [-Wunused-variable] in arch/riscv/kernel/cpu.o (arch/riscv/kernel/cpufeature.c) [logspec:kbuild,kbuild.compiler.warning] --- - dashboard: https://d.kernelci.org/i/maestro:5135288c90855e0205f0a76b012c159c9f2e4f97 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 2e86ed6526626d22b225d03a7faf8bd09dca2a5b Log excerpt: ===================================================== arch/riscv/kernel/cpufeature.c:107:37: warning: unused variable ‘ext_end’ [-Wunused-variable] 107 | const char *ext_end = isa; | ^~~~~~~ arch/riscv/kernel/cpu.c: In function ‘riscv_of_processor_hartid’: arch/riscv/kernel/cpu.c:24:33: error: implicit declaration of function ‘of_get_cpu_hwid’; did you mean ‘of_get_cpu_node’? [-Werror=implicit-function-declaration] 24 | *hart = (unsigned long) of_get_cpu_hwid(node, 0); | ^~~~~~~~~~~~~~~ | of_get_cpu_node cc1: some warnings being treated as errors ===================================================== # Builds where the incident occurred: ## defconfig on (riscv): - compiler: gcc-12 - config: https://files.kernelci.org/kbuild-gcc-12-riscv-68ff67651198e7d4c92ca10f/.co… - dashboard: https://d.kernelci.org/build/maestro:68ff67651198e7d4c92ca10f ## nommu_k210_defconfig on (riscv): - compiler: gcc-12 - config: https://files.kernelci.org/kbuild-gcc-12-riscv-nommu_k210_defconfig-68ff66e… - dashboard: https://d.kernelci.org/build/maestro:68ff66e91198e7d4c92ca077 #kernelci issue maestro:5135288c90855e0205f0a76b012c159c9f2e4f97 Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

1 week, 1 day

1
0
0 0

FAILED: patch "[PATCH] devcoredump: Fix circular locking dependency with" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x a91c8096590bd7801a26454789f2992094fe36da # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102625-cringing-unstuck-790a@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a91c8096590bd7801a26454789f2992094fe36da Mon Sep 17 00:00:00 2001 From: Maarten Lankhorst <dev(a)lankhorst.se> Date: Wed, 23 Jul 2025 16:24:16 +0200 Subject: [PATCH] devcoredump: Fix circular locking dependency with devcd->mutex. The original code causes a circular locking dependency found by lockdep. ====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 Tainted: G S U ------------------------------------------------------ xe_fault_inject/5091 is trying to acquire lock: ffff888156815688 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}, at: __flush_work+0x25d/0x660 but task is already holding lock: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&devcd->mutex){+.+.}-{3:3}: mutex_lock_nested+0x4e/0xc0 devcd_data_write+0x27/0x90 sysfs_kf_bin_write+0x80/0xf0 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (kn->active#236){++++}-{0:0}: kernfs_drain+0x1e2/0x200 __kernfs_remove+0xae/0x400 kernfs_remove_by_name_ns+0x5d/0xc0 remove_files+0x54/0x70 sysfs_remove_group+0x3d/0xa0 sysfs_remove_groups+0x2e/0x60 device_remove_attrs+0xc7/0x100 device_del+0x15d/0x3b0 devcd_del+0x19/0x30 process_one_work+0x22b/0x6f0 worker_thread+0x1e8/0x3d0 kthread+0x11c/0x250 ret_from_fork+0x26c/0x2e0 ret_from_fork_asm+0x1a/0x30 -> #0 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}: __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 __flush_work+0x27a/0x660 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: (work_completion)(&(&devcd->del_wk)->work) --> kn->active#236 --> &devcd->mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&devcd->mutex); lock(kn->active#236); lock(&devcd->mutex); lock((work_completion)(&(&devcd->del_wk)->work)); *** DEADLOCK *** 5 locks held by xe_fault_inject/5091: #0: ffff8881129f9488 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x72/0xf0 #1: ffff88810c755078 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x123/0x220 #2: ffff8881054811a0 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x55/0x280 #3: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 #4: ffffffff8359e020 (rcu_read_lock){....}-{1:2}, at: __flush_work+0x72/0x660 stack backtrace: CPU: 14 UID: 0 PID: 5091 Comm: xe_fault_inject Tainted: G S U 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 PREEMPT_{RT,(lazy)} Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name: Micro-Star International Co., Ltd. MS-7D25/PRO Z690-A DDR4(MS-7D25), BIOS 1.10 12/13/2021 Call Trace: <TASK> dump_stack_lvl+0x91/0xf0 dump_stack+0x10/0x20 print_circular_bug+0x285/0x360 check_noncircular+0x135/0x150 ? register_lock_class+0x48/0x4a0 __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 ? __flush_work+0x25d/0x660 ? mark_held_locks+0x46/0x90 ? __flush_work+0x25d/0x660 __flush_work+0x27a/0x660 ? __flush_work+0x25d/0x660 ? trace_hardirqs_on+0x1e/0xd0 ? __pfx_wq_barrier_func+0x10/0x10 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 ? bus_find_device+0xa8/0xe0 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 ? __f_unlock_pos+0x15/0x20 ? __x64_sys_getdents64+0x9b/0x130 ? __pfx_filldir64+0x10/0x10 ? do_syscall_64+0x1a2/0xb60 ? clear_bhb_loop+0x30/0x80 ? clear_bhb_loop+0x30/0x80 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x76e292edd574 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007fffe247a828 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000076e292edd574 RDX: 000000000000000c RSI: 00006267f6306063 RDI: 000000000000000b RBP: 000000000000000c R08: 000076e292fc4b20 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00006267f6306063 R13: 000000000000000b R14: 00006267e6859c00 R15: 000076e29322a000 </TASK> xe 0000:03:00.0: [drm] Xe device coredump has been deleted. Fixes: 01daccf74832 ("devcoredump : Serialize devcd_del work") Cc: Mukesh Ojha <quic_mojha(a)quicinc.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Johannes Berg <johannes(a)sipsolutions.net> Cc: Rafael J. Wysocki <rafael(a)kernel.org> Cc: Danilo Krummrich <dakr(a)kernel.org> Cc: linux-kernel(a)vger.kernel.org Cc: stable(a)vger.kernel.org # v6.1+ Signed-off-by: Maarten Lankhorst <dev(a)lankhorst.se> Cc: Matthew Brost <matthew.brost(a)intel.com> Acked-by: Mukesh Ojha <mukesh.ojha(a)oss.qualcomm.com> Link: https://lore.kernel.org/r/20250723142416.1020423-1-dev@lankhorst.se Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c index 37faf6156d7c..55bdc7f5e59d 100644 --- a/drivers/base/devcoredump.c +++ b/drivers/base/devcoredump.c @@ -23,50 +23,46 @@ struct devcd_entry { void *data; size_t datalen; /* - * Here, mutex is required to serialize the calls to del_wk work between - * user/kernel space which happens when devcd is added with device_add() - * and that sends uevent to user space. User space reads the uevents, - * and calls to devcd_data_write() which try to modify the work which is - * not even initialized/queued from devcoredump. + * There are 2 races for which mutex is required. * + * The first race is between device creation and userspace writing to + * schedule immediately destruction. * + * This race is handled by arming the timer before device creation, but + * when device creation fails the timer still exists. * - * cpu0(X) cpu1(Y) + * To solve this, hold the mutex during device_add(), and set + * init_completed on success before releasing the mutex. * - * dev_coredump() uevent sent to user space - * device_add() ======================> user space process Y reads the - * uevents writes to devcd fd - * which results into writes to + * That way the timer will never fire until device_add() is called, + * it will do nothing if init_completed is not set. The timer is also + * cancelled in that case. * - * devcd_data_write() - * mod_delayed_work() - * try_to_grab_pending() - * timer_delete() - * debug_assert_init() - * INIT_DELAYED_WORK() - * schedule_delayed_work() - * - * - * Also, mutex alone would not be enough to avoid scheduling of - * del_wk work after it get flush from a call to devcd_free() - * mentioned as below. - * - * disabled_store() - * devcd_free() - * mutex_lock() devcd_data_write() - * flush_delayed_work() - * mutex_unlock() - * mutex_lock() - * mod_delayed_work() - * mutex_unlock() - * So, delete_work flag is required. + * The second race involves multiple parallel invocations of devcd_free(), + * add a deleted flag so only 1 can call the destructor. */ struct mutex mutex; - bool delete_work; + bool init_completed, deleted; struct module *owner; ssize_t (*read)(char *buffer, loff_t offset, size_t count, void *data, size_t datalen); void (*free)(void *data); + /* + * If nothing interferes and device_add() was returns success, + * del_wk will destroy the device after the timer fires. + * + * Multiple userspace processes can interfere in the working of the timer: + * - Writing to the coredump will reschedule the timer to run immediately, + * if still armed. + * + * This is handled by using "if (cancel_delayed_work()) { + * schedule_delayed_work() }", to prevent re-arming after having + * been previously fired. + * - Writing to /sys/class/devcoredump/disabled will destroy the + * coredump synchronously. + * This is handled by using disable_delayed_work_sync(), and then + * checking if deleted flag is set with &devcd->mutex held. + */ struct delayed_work del_wk; struct device *failing_dev; }; @@ -95,14 +91,27 @@ static void devcd_dev_release(struct device *dev) kfree(devcd); } +static void __devcd_del(struct devcd_entry *devcd) +{ + devcd->deleted = true; + device_del(&devcd->devcd_dev); + put_device(&devcd->devcd_dev); +} + static void devcd_del(struct work_struct *wk) { struct devcd_entry *devcd; + bool init_completed; devcd = container_of(wk, struct devcd_entry, del_wk.work); - device_del(&devcd->devcd_dev); - put_device(&devcd->devcd_dev); + /* devcd->mutex serializes against dev_coredumpm_timeout */ + mutex_lock(&devcd->mutex); + init_completed = devcd->init_completed; + mutex_unlock(&devcd->mutex); + + if (init_completed) + __devcd_del(devcd); } static ssize_t devcd_data_read(struct file *filp, struct kobject *kobj, @@ -122,12 +131,12 @@ static ssize_t devcd_data_write(struct file *filp, struct kobject *kobj, struct device *dev = kobj_to_dev(kobj); struct devcd_entry *devcd = dev_to_devcd(dev); - mutex_lock(&devcd->mutex); - if (!devcd->delete_work) { - devcd->delete_work = true; - mod_delayed_work(system_wq, &devcd->del_wk, 0); - } - mutex_unlock(&devcd->mutex); + /* + * Although it's tempting to use mod_delayed work here, + * that will cause a reschedule if the timer already fired. + */ + if (cancel_delayed_work(&devcd->del_wk)) + schedule_delayed_work(&devcd->del_wk, 0); return count; } @@ -151,11 +160,21 @@ static int devcd_free(struct device *dev, void *data) { struct devcd_entry *devcd = dev_to_devcd(dev); + /* + * To prevent a race with devcd_data_write(), disable work and + * complete manually instead. + * + * We cannot rely on the return value of + * disable_delayed_work_sync() here, because it might be in the + * middle of a cancel_delayed_work + schedule_delayed_work pair. + * + * devcd->mutex here guards against multiple parallel invocations + * of devcd_free(). + */ + disable_delayed_work_sync(&devcd->del_wk); mutex_lock(&devcd->mutex); - if (!devcd->delete_work) - devcd->delete_work = true; - - flush_delayed_work(&devcd->del_wk); + if (!devcd->deleted) + __devcd_del(devcd); mutex_unlock(&devcd->mutex); return 0; } @@ -179,12 +198,10 @@ static ssize_t disabled_show(const struct class *class, const struct class_attri * put_device() <- last reference * error = fn(dev, data) devcd_dev_release() * devcd_free(dev, data) kfree(devcd) - * mutex_lock(&devcd->mutex); * * * In the above diagram, it looks like disabled_store() would be racing with parallelly - * running devcd_del() and result in memory abort while acquiring devcd->mutex which - * is called after kfree of devcd memory after dropping its last reference with + * running devcd_del() and result in memory abort after dropping its last reference with * put_device(). However, this will not happens as fn(dev, data) runs * with its own reference to device via klist_node so it is not its last reference. * so, above situation would not occur. @@ -374,7 +391,7 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, devcd->read = read; devcd->free = free; devcd->failing_dev = get_device(dev); - devcd->delete_work = false; + devcd->deleted = false; mutex_init(&devcd->mutex); device_initialize(&devcd->devcd_dev); @@ -383,8 +400,14 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, atomic_inc_return(&devcd_count)); devcd->devcd_dev.class = &devcd_class; - mutex_lock(&devcd->mutex); dev_set_uevent_suppress(&devcd->devcd_dev, true); + + /* devcd->mutex prevents devcd_del() completing until init finishes */ + mutex_lock(&devcd->mutex); + devcd->init_completed = false; + INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); + schedule_delayed_work(&devcd->del_wk, timeout); + if (device_add(&devcd->devcd_dev)) goto put_device; @@ -401,13 +424,20 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, dev_set_uevent_suppress(&devcd->devcd_dev, false); kobject_uevent(&devcd->devcd_dev.kobj, KOBJ_ADD); - INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); - schedule_delayed_work(&devcd->del_wk, timeout); + + /* + * Safe to run devcd_del() now that we are done with devcd_dev. + * Alternatively we could have taken a ref on devcd_dev before + * dropping the lock. + */ + devcd->init_completed = true; mutex_unlock(&devcd->mutex); return; put_device: - put_device(&devcd->devcd_dev); mutex_unlock(&devcd->mutex); + cancel_delayed_work_sync(&devcd->del_wk); + put_device(&devcd->devcd_dev); + put_module: module_put(owner); free:

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] xfs: always warn about deprecated mount options" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 630785bfbe12c3ee3ebccd8b530a98d632b7e39d # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102617-untrimmed-ideally-b80b@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 630785bfbe12c3ee3ebccd8b530a98d632b7e39d Mon Sep 17 00:00:00 2001 From: "Darrick J. Wong" <djwong(a)kernel.org> Date: Tue, 21 Oct 2025 11:30:12 -0700 Subject: [PATCH] xfs: always warn about deprecated mount options The deprecation of the 'attr2' mount option in 6.18 wasn't entirely successful because nobody noticed that the kernel never printed a warning about attr2 being set in fstab if the only xfs filesystem is the root fs; the initramfs mounts the root fs with no mount options; and the init scripts only conveyed the fstab options by remounting the root fs. Fix this by making it complain all the time. Cc: stable(a)vger.kernel.org # v5.13 Fixes: 92cf7d36384b99 ("xfs: Skip repetitive warnings about mount options") Signed-off-by: Darrick J. Wong <djwong(a)kernel.org> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Carlos Maiolino <cmaiolino(a)redhat.com> Signed-off-by: Carlos Maiolino <cem(a)kernel.org> diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c index 9d51186b24dd..c53f2edf92e7 100644 --- a/fs/xfs/xfs_super.c +++ b/fs/xfs/xfs_super.c @@ -1379,16 +1379,25 @@ suffix_kstrtoull( static inline void xfs_fs_warn_deprecated( struct fs_context *fc, - struct fs_parameter *param, - uint64_t flag, - bool value) + struct fs_parameter *param) { - /* Don't print the warning if reconfiguring and current mount point - * already had the flag set + /* + * Always warn about someone passing in a deprecated mount option. + * Previously we wouldn't print the warning if we were reconfiguring + * and current mount point already had the flag set, but that was not + * the right thing to do. + * + * Many distributions mount the root filesystem with no options in the + * initramfs and rely on mount -a to remount the root fs with the + * options in fstab. However, the old behavior meant that there would + * never be a warning about deprecated mount options for the root fs in + * /etc/fstab. On a single-fs system, that means no warning at all. + * + * Compounding this problem are distribution scripts that copy + * /proc/mounts to fstab, which means that we can't remove mount + * options unless we're 100% sure they have only ever been advertised + * in /proc/mounts in response to explicitly provided mount options. */ - if ((fc->purpose & FS_CONTEXT_FOR_RECONFIGURE) && - !!(XFS_M(fc->root->d_sb)->m_features & flag) == value) - return; xfs_warn(fc->s_fs_info, "%s mount option is deprecated.", param->key); }

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] net: ravb: Enforce descriptor type ordering" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 5370c31e84b0e0999c7b5ff949f4e104def35584 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102623-footless-outcast-b793@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5370c31e84b0e0999c7b5ff949f4e104def35584 Mon Sep 17 00:00:00 2001 From: Lad Prabhakar <prabhakar.mahadev-lad.rj(a)bp.renesas.com> Date: Fri, 17 Oct 2025 16:18:29 +0100 Subject: [PATCH] net: ravb: Enforce descriptor type ordering MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Ensure the TX descriptor type fields are published in a safe order so the DMA engine never begins processing a descriptor chain before all descriptor fields are fully initialised. For multi-descriptor transmits the driver writes DT_FEND into the last descriptor and DT_FSTART into the first. The DMA engine begins processing when it observes DT_FSTART. Move the dma_wmb() barrier so it executes immediately after DT_FEND and immediately before writing DT_FSTART (and before DT_FSINGLE in the single-descriptor case). This guarantees that all prior CPU writes to the descriptor memory are visible to the device before DT_FSTART is seen. This avoids a situation where compiler/CPU reordering could publish DT_FSTART ahead of DT_FEND or other descriptor fields, allowing the DMA to start on a partially initialised chain and causing corrupted transmissions or TX timeouts. Such a failure was observed on RZ/G2L with an RT kernel as transmit queue timeouts and device resets. Fixes: 2f45d1902acf ("ravb: minimize TX data copying") Cc: stable(a)vger.kernel.org Co-developed-by: Fabrizio Castro <fabrizio.castro.jz(a)renesas.com> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz(a)renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj(a)bp.renesas.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas(a)ragnatech.se> Link: https://patch.msgid.link/20251017151830.171062-4-prabhakar.mahadev-lad.rj@b… Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c index 9d3bd65b85ff..044ee83c63bb 100644 --- a/drivers/net/ethernet/renesas/ravb_main.c +++ b/drivers/net/ethernet/renesas/ravb_main.c @@ -2211,13 +2211,25 @@ static netdev_tx_t ravb_start_xmit(struct sk_buff *skb, struct net_device *ndev) skb_tx_timestamp(skb); } - /* Descriptor type must be set after all the above writes */ - dma_wmb(); + if (num_tx_desc > 1) { desc->die_dt = DT_FEND; desc--; + /* When using multi-descriptors, DT_FEND needs to get written + * before DT_FSTART, but the compiler may reorder the memory + * writes in an attempt to optimize the code. + * Use a dma_wmb() barrier to make sure DT_FEND and DT_FSTART + * are written exactly in the order shown in the code. + * This is particularly important for cases where the DMA engine + * is already running when we are running this code. If the DMA + * sees DT_FSTART without the corresponding DT_FEND it will enter + * an error condition. + */ + dma_wmb(); desc->die_dt = DT_FSTART; } else { + /* Descriptor type must be set after all the above writes */ + dma_wmb(); desc->die_dt = DT_FSINGLE; } ravb_modify(ndev, TCCR, TCCR_TSRQ0 << q, TCCR_TSRQ0 << q);

1 week, 1 day

2
2
0 0

FAILED: patch "[PATCH] devcoredump: Fix circular locking dependency with" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x a91c8096590bd7801a26454789f2992094fe36da # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102624-aspect-stumble-aea9@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From a91c8096590bd7801a26454789f2992094fe36da Mon Sep 17 00:00:00 2001 From: Maarten Lankhorst <dev(a)lankhorst.se> Date: Wed, 23 Jul 2025 16:24:16 +0200 Subject: [PATCH] devcoredump: Fix circular locking dependency with devcd->mutex. The original code causes a circular locking dependency found by lockdep. ====================================================== WARNING: possible circular locking dependency detected 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 Tainted: G S U ------------------------------------------------------ xe_fault_inject/5091 is trying to acquire lock: ffff888156815688 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}, at: __flush_work+0x25d/0x660 but task is already holding lock: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&devcd->mutex){+.+.}-{3:3}: mutex_lock_nested+0x4e/0xc0 devcd_data_write+0x27/0x90 sysfs_kf_bin_write+0x80/0xf0 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (kn->active#236){++++}-{0:0}: kernfs_drain+0x1e2/0x200 __kernfs_remove+0xae/0x400 kernfs_remove_by_name_ns+0x5d/0xc0 remove_files+0x54/0x70 sysfs_remove_group+0x3d/0xa0 sysfs_remove_groups+0x2e/0x60 device_remove_attrs+0xc7/0x100 device_del+0x15d/0x3b0 devcd_del+0x19/0x30 process_one_work+0x22b/0x6f0 worker_thread+0x1e8/0x3d0 kthread+0x11c/0x250 ret_from_fork+0x26c/0x2e0 ret_from_fork_asm+0x1a/0x30 -> #0 ((work_completion)(&(&devcd->del_wk)->work)){+.+.}-{0:0}: __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 __flush_work+0x27a/0x660 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 entry_SYSCALL_64_after_hwframe+0x76/0x7e other info that might help us debug this: Chain exists of: (work_completion)(&(&devcd->del_wk)->work) --> kn->active#236 --> &devcd->mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&devcd->mutex); lock(kn->active#236); lock(&devcd->mutex); lock((work_completion)(&(&devcd->del_wk)->work)); *** DEADLOCK *** 5 locks held by xe_fault_inject/5091: #0: ffff8881129f9488 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x72/0xf0 #1: ffff88810c755078 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x123/0x220 #2: ffff8881054811a0 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x55/0x280 #3: ffff888156815620 (&devcd->mutex){+.+.}-{3:3}, at: dev_coredump_put+0x3f/0xa0 #4: ffffffff8359e020 (rcu_read_lock){....}-{1:2}, at: __flush_work+0x72/0x660 stack backtrace: CPU: 14 UID: 0 PID: 5091 Comm: xe_fault_inject Tainted: G S U 6.16.0-rc6-lgci-xe-xe-pw-151626v3+ #1 PREEMPT_{RT,(lazy)} Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER Hardware name: Micro-Star International Co., Ltd. MS-7D25/PRO Z690-A DDR4(MS-7D25), BIOS 1.10 12/13/2021 Call Trace: <TASK> dump_stack_lvl+0x91/0xf0 dump_stack+0x10/0x20 print_circular_bug+0x285/0x360 check_noncircular+0x135/0x150 ? register_lock_class+0x48/0x4a0 __lock_acquire+0x1661/0x2860 lock_acquire+0xc4/0x2f0 ? __flush_work+0x25d/0x660 ? mark_held_locks+0x46/0x90 ? __flush_work+0x25d/0x660 __flush_work+0x27a/0x660 ? __flush_work+0x25d/0x660 ? trace_hardirqs_on+0x1e/0xd0 ? __pfx_wq_barrier_func+0x10/0x10 flush_delayed_work+0x5d/0xa0 dev_coredump_put+0x63/0xa0 xe_driver_devcoredump_fini+0x12/0x20 [xe] devm_action_release+0x12/0x30 release_nodes+0x3a/0x120 devres_release_all+0x8a/0xd0 device_unbind_cleanup+0x12/0x80 device_release_driver_internal+0x23a/0x280 ? bus_find_device+0xa8/0xe0 device_driver_detach+0x14/0x20 unbind_store+0xaf/0xc0 drv_attr_store+0x21/0x50 sysfs_kf_write+0x4a/0x80 kernfs_fop_write_iter+0x169/0x220 vfs_write+0x293/0x560 ksys_write+0x72/0xf0 __x64_sys_write+0x19/0x30 x64_sys_call+0x2bf/0x2660 do_syscall_64+0x93/0xb60 ? __f_unlock_pos+0x15/0x20 ? __x64_sys_getdents64+0x9b/0x130 ? __pfx_filldir64+0x10/0x10 ? do_syscall_64+0x1a2/0xb60 ? clear_bhb_loop+0x30/0x80 ? clear_bhb_loop+0x30/0x80 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x76e292edd574 Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89 RSP: 002b:00007fffe247a828 EFLAGS: 00000202 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 000076e292edd574 RDX: 000000000000000c RSI: 00006267f6306063 RDI: 000000000000000b RBP: 000000000000000c R08: 000076e292fc4b20 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00006267f6306063 R13: 000000000000000b R14: 00006267e6859c00 R15: 000076e29322a000 </TASK> xe 0000:03:00.0: [drm] Xe device coredump has been deleted. Fixes: 01daccf74832 ("devcoredump : Serialize devcd_del work") Cc: Mukesh Ojha <quic_mojha(a)quicinc.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Johannes Berg <johannes(a)sipsolutions.net> Cc: Rafael J. Wysocki <rafael(a)kernel.org> Cc: Danilo Krummrich <dakr(a)kernel.org> Cc: linux-kernel(a)vger.kernel.org Cc: stable(a)vger.kernel.org # v6.1+ Signed-off-by: Maarten Lankhorst <dev(a)lankhorst.se> Cc: Matthew Brost <matthew.brost(a)intel.com> Acked-by: Mukesh Ojha <mukesh.ojha(a)oss.qualcomm.com> Link: https://lore.kernel.org/r/20250723142416.1020423-1-dev@lankhorst.se Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/base/devcoredump.c b/drivers/base/devcoredump.c index 37faf6156d7c..55bdc7f5e59d 100644 --- a/drivers/base/devcoredump.c +++ b/drivers/base/devcoredump.c @@ -23,50 +23,46 @@ struct devcd_entry { void *data; size_t datalen; /* - * Here, mutex is required to serialize the calls to del_wk work between - * user/kernel space which happens when devcd is added with device_add() - * and that sends uevent to user space. User space reads the uevents, - * and calls to devcd_data_write() which try to modify the work which is - * not even initialized/queued from devcoredump. + * There are 2 races for which mutex is required. * + * The first race is between device creation and userspace writing to + * schedule immediately destruction. * + * This race is handled by arming the timer before device creation, but + * when device creation fails the timer still exists. * - * cpu0(X) cpu1(Y) + * To solve this, hold the mutex during device_add(), and set + * init_completed on success before releasing the mutex. * - * dev_coredump() uevent sent to user space - * device_add() ======================> user space process Y reads the - * uevents writes to devcd fd - * which results into writes to + * That way the timer will never fire until device_add() is called, + * it will do nothing if init_completed is not set. The timer is also + * cancelled in that case. * - * devcd_data_write() - * mod_delayed_work() - * try_to_grab_pending() - * timer_delete() - * debug_assert_init() - * INIT_DELAYED_WORK() - * schedule_delayed_work() - * - * - * Also, mutex alone would not be enough to avoid scheduling of - * del_wk work after it get flush from a call to devcd_free() - * mentioned as below. - * - * disabled_store() - * devcd_free() - * mutex_lock() devcd_data_write() - * flush_delayed_work() - * mutex_unlock() - * mutex_lock() - * mod_delayed_work() - * mutex_unlock() - * So, delete_work flag is required. + * The second race involves multiple parallel invocations of devcd_free(), + * add a deleted flag so only 1 can call the destructor. */ struct mutex mutex; - bool delete_work; + bool init_completed, deleted; struct module *owner; ssize_t (*read)(char *buffer, loff_t offset, size_t count, void *data, size_t datalen); void (*free)(void *data); + /* + * If nothing interferes and device_add() was returns success, + * del_wk will destroy the device after the timer fires. + * + * Multiple userspace processes can interfere in the working of the timer: + * - Writing to the coredump will reschedule the timer to run immediately, + * if still armed. + * + * This is handled by using "if (cancel_delayed_work()) { + * schedule_delayed_work() }", to prevent re-arming after having + * been previously fired. + * - Writing to /sys/class/devcoredump/disabled will destroy the + * coredump synchronously. + * This is handled by using disable_delayed_work_sync(), and then + * checking if deleted flag is set with &devcd->mutex held. + */ struct delayed_work del_wk; struct device *failing_dev; }; @@ -95,14 +91,27 @@ static void devcd_dev_release(struct device *dev) kfree(devcd); } +static void __devcd_del(struct devcd_entry *devcd) +{ + devcd->deleted = true; + device_del(&devcd->devcd_dev); + put_device(&devcd->devcd_dev); +} + static void devcd_del(struct work_struct *wk) { struct devcd_entry *devcd; + bool init_completed; devcd = container_of(wk, struct devcd_entry, del_wk.work); - device_del(&devcd->devcd_dev); - put_device(&devcd->devcd_dev); + /* devcd->mutex serializes against dev_coredumpm_timeout */ + mutex_lock(&devcd->mutex); + init_completed = devcd->init_completed; + mutex_unlock(&devcd->mutex); + + if (init_completed) + __devcd_del(devcd); } static ssize_t devcd_data_read(struct file *filp, struct kobject *kobj, @@ -122,12 +131,12 @@ static ssize_t devcd_data_write(struct file *filp, struct kobject *kobj, struct device *dev = kobj_to_dev(kobj); struct devcd_entry *devcd = dev_to_devcd(dev); - mutex_lock(&devcd->mutex); - if (!devcd->delete_work) { - devcd->delete_work = true; - mod_delayed_work(system_wq, &devcd->del_wk, 0); - } - mutex_unlock(&devcd->mutex); + /* + * Although it's tempting to use mod_delayed work here, + * that will cause a reschedule if the timer already fired. + */ + if (cancel_delayed_work(&devcd->del_wk)) + schedule_delayed_work(&devcd->del_wk, 0); return count; } @@ -151,11 +160,21 @@ static int devcd_free(struct device *dev, void *data) { struct devcd_entry *devcd = dev_to_devcd(dev); + /* + * To prevent a race with devcd_data_write(), disable work and + * complete manually instead. + * + * We cannot rely on the return value of + * disable_delayed_work_sync() here, because it might be in the + * middle of a cancel_delayed_work + schedule_delayed_work pair. + * + * devcd->mutex here guards against multiple parallel invocations + * of devcd_free(). + */ + disable_delayed_work_sync(&devcd->del_wk); mutex_lock(&devcd->mutex); - if (!devcd->delete_work) - devcd->delete_work = true; - - flush_delayed_work(&devcd->del_wk); + if (!devcd->deleted) + __devcd_del(devcd); mutex_unlock(&devcd->mutex); return 0; } @@ -179,12 +198,10 @@ static ssize_t disabled_show(const struct class *class, const struct class_attri * put_device() <- last reference * error = fn(dev, data) devcd_dev_release() * devcd_free(dev, data) kfree(devcd) - * mutex_lock(&devcd->mutex); * * * In the above diagram, it looks like disabled_store() would be racing with parallelly - * running devcd_del() and result in memory abort while acquiring devcd->mutex which - * is called after kfree of devcd memory after dropping its last reference with + * running devcd_del() and result in memory abort after dropping its last reference with * put_device(). However, this will not happens as fn(dev, data) runs * with its own reference to device via klist_node so it is not its last reference. * so, above situation would not occur. @@ -374,7 +391,7 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, devcd->read = read; devcd->free = free; devcd->failing_dev = get_device(dev); - devcd->delete_work = false; + devcd->deleted = false; mutex_init(&devcd->mutex); device_initialize(&devcd->devcd_dev); @@ -383,8 +400,14 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, atomic_inc_return(&devcd_count)); devcd->devcd_dev.class = &devcd_class; - mutex_lock(&devcd->mutex); dev_set_uevent_suppress(&devcd->devcd_dev, true); + + /* devcd->mutex prevents devcd_del() completing until init finishes */ + mutex_lock(&devcd->mutex); + devcd->init_completed = false; + INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); + schedule_delayed_work(&devcd->del_wk, timeout); + if (device_add(&devcd->devcd_dev)) goto put_device; @@ -401,13 +424,20 @@ void dev_coredumpm_timeout(struct device *dev, struct module *owner, dev_set_uevent_suppress(&devcd->devcd_dev, false); kobject_uevent(&devcd->devcd_dev.kobj, KOBJ_ADD); - INIT_DELAYED_WORK(&devcd->del_wk, devcd_del); - schedule_delayed_work(&devcd->del_wk, timeout); + + /* + * Safe to run devcd_del() now that we are done with devcd_dev. + * Alternatively we could have taken a ref on devcd_dev before + * dropping the lock. + */ + devcd->init_completed = true; mutex_unlock(&devcd->mutex); return; put_device: - put_device(&devcd->devcd_dev); mutex_unlock(&devcd->mutex); + cancel_delayed_work_sync(&devcd->del_wk); + put_device(&devcd->devcd_dev); + put_module: module_put(owner); free:

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] can: gs_usb: increase max interface to U8_MAX" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y git checkout FETCH_HEAD git cherry-pick -x 2a27f6a8fb5722223d526843040f747e9b0e8060 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102041-mounting-pursuit-e9d3@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2a27f6a8fb5722223d526843040f747e9b0e8060 Mon Sep 17 00:00:00 2001 From: Celeste Liu <uwu(a)coelacanthus.name> Date: Tue, 30 Sep 2025 19:34:28 +0800 Subject: [PATCH] can: gs_usb: increase max interface to U8_MAX This issue was found by Runcheng Lu when develop HSCanT USB to CAN FD converter[1]. The original developers may have only 3 interfaces device to test so they write 3 here and wait for future change. During the HSCanT development, we actually used 4 interfaces, so the limitation of 3 is not enough now. But just increase one is not future-proofed. Since the channel index type in gs_host_frame is u8, just make canch[] become a flexible array with a u8 index, so it naturally constraint by U8_MAX and avoid statically allocate 256 pointer for every gs_usb device. [1]: https://github.com/cherry-embedded/HSCanT-hardware Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Reported-by: Runcheng Lu <runcheng.lu(a)hpmicro.com> Cc: stable(a)vger.kernel.org Reviewed-by: Vincent Mailhol <mailhol(a)kernel.org> Signed-off-by: Celeste Liu <uwu(a)coelacanthus.name> Link: https://patch.msgid.link/20250930-gs-usb-max-if-v5-1-863330bf6666@coelacant… Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c index c9482d6e947b..9fb4cbbd6d6d 100644 --- a/drivers/net/can/usb/gs_usb.c +++ b/drivers/net/can/usb/gs_usb.c @@ -289,11 +289,6 @@ struct gs_host_frame { #define GS_MAX_RX_URBS 30 #define GS_NAPI_WEIGHT 32 -/* Maximum number of interfaces the driver supports per device. - * Current hardware only supports 3 interfaces. The future may vary. - */ -#define GS_MAX_INTF 3 - struct gs_tx_context { struct gs_can *dev; unsigned int echo_id; @@ -324,7 +319,6 @@ struct gs_can { /* usb interface struct */ struct gs_usb { - struct gs_can *canch[GS_MAX_INTF]; struct usb_anchor rx_submitted; struct usb_device *udev; @@ -336,9 +330,11 @@ struct gs_usb { unsigned int hf_size_rx; u8 active_channels; + u8 channel_cnt; unsigned int pipe_in; unsigned int pipe_out; + struct gs_can *canch[] __counted_by(channel_cnt); }; /* 'allocate' a tx context. @@ -599,7 +595,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb) } /* device reports out of range channel id */ - if (hf->channel >= GS_MAX_INTF) + if (hf->channel >= parent->channel_cnt) goto device_detach; dev = parent->canch[hf->channel]; @@ -699,7 +695,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb) /* USB failure take down all interfaces */ if (rc == -ENODEV) { device_detach: - for (rc = 0; rc < GS_MAX_INTF; rc++) { + for (rc = 0; rc < parent->channel_cnt; rc++) { if (parent->canch[rc]) netif_device_detach(parent->canch[rc]->netdev); } @@ -1460,17 +1456,19 @@ static int gs_usb_probe(struct usb_interface *intf, icount = dconf.icount + 1; dev_info(&intf->dev, "Configuring for %u interfaces\n", icount); - if (icount > GS_MAX_INTF) { + if (icount > type_max(parent->channel_cnt)) { dev_err(&intf->dev, "Driver cannot handle more that %u CAN interfaces\n", - GS_MAX_INTF); + type_max(parent->channel_cnt)); return -EINVAL; } - parent = kzalloc(sizeof(*parent), GFP_KERNEL); + parent = kzalloc(struct_size(parent, canch, icount), GFP_KERNEL); if (!parent) return -ENOMEM; + parent->channel_cnt = icount; + init_usb_anchor(&parent->rx_submitted); usb_set_intfdata(intf, parent); @@ -1531,7 +1529,7 @@ static void gs_usb_disconnect(struct usb_interface *intf) return; } - for (i = 0; i < GS_MAX_INTF; i++) + for (i = 0; i < parent->channel_cnt; i++) if (parent->canch[i]) gs_destroy_candev(parent->canch[i]);

1 week, 1 day

3
4
0 0

[PATCH] drm/nouveau: Fix race in nouveau_sched_fini()

by Philipp Stanner

nouveau_sched_fini() uses a memory barrier before wait_event(). wait_event(), however, is a macro which expands to a loop which might check the passed condition several times. The barrier would only take effect for the first check. Replace the barrier with a function which takes the spinlock. Cc: stable(a)vger.kernel.org # v6.8+ Fixes: 5f03a507b29e ("drm/nouveau: implement 1:1 scheduler - entity relationship") Signed-off-by: Philipp Stanner <phasta(a)kernel.org> --- drivers/gpu/drm/nouveau/nouveau_sched.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_sched.c b/drivers/gpu/drm/nouveau/nouveau_sched.c index e60f7892f5ce..a7bf539e5d86 100644 --- a/drivers/gpu/drm/nouveau/nouveau_sched.c +++ b/drivers/gpu/drm/nouveau/nouveau_sched.c @@ -482,6 +482,17 @@ nouveau_sched_create(struct nouveau_sched **psched, struct nouveau_drm *drm, return 0; } +static bool +nouveau_sched_job_list_empty(struct nouveau_sched *sched) +{ + bool empty; + + spin_lock(&sched->job.list.lock); + empty = list_empty(&sched->job.list.head); + spin_unlock(&sched->job.list.lock); + + return empty; +} static void nouveau_sched_fini(struct nouveau_sched *sched) @@ -489,8 +500,7 @@ nouveau_sched_fini(struct nouveau_sched *sched) struct drm_gpu_scheduler *drm_sched = &sched->base; struct drm_sched_entity *entity = &sched->entity; - rmb(); /* for list_empty to work without lock */ - wait_event(sched->job.wq, list_empty(&sched->job.list.head)); + wait_event(sched->job.wq, nouveau_sched_job_list_empty(sched)); drm_sched_entity_fini(entity); drm_sched_fini(drm_sched); -- 2.49.0

1 week, 1 day

3
2
0 0

FAILED: patch "[PATCH] can: gs_usb: increase max interface to U8_MAX" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x 2a27f6a8fb5722223d526843040f747e9b0e8060 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102040-unusual-concur-90e9@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2a27f6a8fb5722223d526843040f747e9b0e8060 Mon Sep 17 00:00:00 2001 From: Celeste Liu <uwu(a)coelacanthus.name> Date: Tue, 30 Sep 2025 19:34:28 +0800 Subject: [PATCH] can: gs_usb: increase max interface to U8_MAX This issue was found by Runcheng Lu when develop HSCanT USB to CAN FD converter[1]. The original developers may have only 3 interfaces device to test so they write 3 here and wait for future change. During the HSCanT development, we actually used 4 interfaces, so the limitation of 3 is not enough now. But just increase one is not future-proofed. Since the channel index type in gs_host_frame is u8, just make canch[] become a flexible array with a u8 index, so it naturally constraint by U8_MAX and avoid statically allocate 256 pointer for every gs_usb device. [1]: https://github.com/cherry-embedded/HSCanT-hardware Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Reported-by: Runcheng Lu <runcheng.lu(a)hpmicro.com> Cc: stable(a)vger.kernel.org Reviewed-by: Vincent Mailhol <mailhol(a)kernel.org> Signed-off-by: Celeste Liu <uwu(a)coelacanthus.name> Link: https://patch.msgid.link/20250930-gs-usb-max-if-v5-1-863330bf6666@coelacant… Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c index c9482d6e947b..9fb4cbbd6d6d 100644 --- a/drivers/net/can/usb/gs_usb.c +++ b/drivers/net/can/usb/gs_usb.c @@ -289,11 +289,6 @@ struct gs_host_frame { #define GS_MAX_RX_URBS 30 #define GS_NAPI_WEIGHT 32 -/* Maximum number of interfaces the driver supports per device. - * Current hardware only supports 3 interfaces. The future may vary. - */ -#define GS_MAX_INTF 3 - struct gs_tx_context { struct gs_can *dev; unsigned int echo_id; @@ -324,7 +319,6 @@ struct gs_can { /* usb interface struct */ struct gs_usb { - struct gs_can *canch[GS_MAX_INTF]; struct usb_anchor rx_submitted; struct usb_device *udev; @@ -336,9 +330,11 @@ struct gs_usb { unsigned int hf_size_rx; u8 active_channels; + u8 channel_cnt; unsigned int pipe_in; unsigned int pipe_out; + struct gs_can *canch[] __counted_by(channel_cnt); }; /* 'allocate' a tx context. @@ -599,7 +595,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb) } /* device reports out of range channel id */ - if (hf->channel >= GS_MAX_INTF) + if (hf->channel >= parent->channel_cnt) goto device_detach; dev = parent->canch[hf->channel]; @@ -699,7 +695,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb) /* USB failure take down all interfaces */ if (rc == -ENODEV) { device_detach: - for (rc = 0; rc < GS_MAX_INTF; rc++) { + for (rc = 0; rc < parent->channel_cnt; rc++) { if (parent->canch[rc]) netif_device_detach(parent->canch[rc]->netdev); } @@ -1460,17 +1456,19 @@ static int gs_usb_probe(struct usb_interface *intf, icount = dconf.icount + 1; dev_info(&intf->dev, "Configuring for %u interfaces\n", icount); - if (icount > GS_MAX_INTF) { + if (icount > type_max(parent->channel_cnt)) { dev_err(&intf->dev, "Driver cannot handle more that %u CAN interfaces\n", - GS_MAX_INTF); + type_max(parent->channel_cnt)); return -EINVAL; } - parent = kzalloc(sizeof(*parent), GFP_KERNEL); + parent = kzalloc(struct_size(parent, canch, icount), GFP_KERNEL); if (!parent) return -ENOMEM; + parent->channel_cnt = icount; + init_usb_anchor(&parent->rx_submitted); usb_set_intfdata(intf, parent); @@ -1531,7 +1529,7 @@ static void gs_usb_disconnect(struct usb_interface *intf) return; } - for (i = 0; i < GS_MAX_INTF; i++) + for (i = 0; i < parent->channel_cnt; i++) if (parent->canch[i]) gs_destroy_candev(parent->canch[i]);

1 week, 1 day

3
6
0 0

[PATCH] drm/sched: Fix race in drm_sched_entity_select_rq()

by Philipp Stanner

In a past bug fix it was forgotten that entity access must be protected by the entity lock. That's a data race and potentially UB. Move the spin_unlock() to the appropriate position. Cc: stable(a)vger.kernel.org # v5.13+ Fixes: ac4eb83ab255 ("drm/sched: select new rq even if there is only one v3") Signed-off-by: Philipp Stanner <phasta(a)kernel.org> --- drivers/gpu/drm/scheduler/sched_entity.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c index 5a4697f636f2..aa222166de58 100644 --- a/drivers/gpu/drm/scheduler/sched_entity.c +++ b/drivers/gpu/drm/scheduler/sched_entity.c @@ -552,10 +552,11 @@ void drm_sched_entity_select_rq(struct drm_sched_entity *entity) drm_sched_rq_remove_entity(entity->rq, entity); entity->rq = rq; } - spin_unlock(&entity->lock); if (entity->num_sched_list == 1) entity->sched_list = NULL; + + spin_unlock(&entity->lock); } /** -- 2.49.0

1 week, 1 day

3
2
0 0

[PATCH] scripts/quilt-mail: add my new email address

by Slade Watkins

My old email address is no longer valid and was bouncing. Add my new one instead. Signed-off-by: Slade Watkins <sr(a)sladewatkins.com> --- scripts/quilt-mail | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/quilt-mail b/scripts/quilt-mail index 9790b65f0f..7ef3f2fdbc 100755 --- a/scripts/quilt-mail +++ b/scripts/quilt-mail @@ -181,7 +181,8 @@ CC_NAMES=("linux-kernel(a)vger\.kernel\.org" "conor(a)kernel\.org" "hargar(a)microsoft\.com" "broonie(a)kernel\.org" - "achill(a)achill\.org") + "achill(a)achill\.org" + "sr(a)sladewatkins\.com") #CC_LIST="stable(a)vger\.kernel\.org" CC_LIST="patches(a)lists.linux.dev" -- 2.50.1 (Apple Git-155)

1 week, 1 day

2
1
0 0

FAILED: patch "[PATCH] can: gs_usb: increase max interface to U8_MAX" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x 2a27f6a8fb5722223d526843040f747e9b0e8060 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102039-detoxify-trustee-aa22@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2a27f6a8fb5722223d526843040f747e9b0e8060 Mon Sep 17 00:00:00 2001 From: Celeste Liu <uwu(a)coelacanthus.name> Date: Tue, 30 Sep 2025 19:34:28 +0800 Subject: [PATCH] can: gs_usb: increase max interface to U8_MAX This issue was found by Runcheng Lu when develop HSCanT USB to CAN FD converter[1]. The original developers may have only 3 interfaces device to test so they write 3 here and wait for future change. During the HSCanT development, we actually used 4 interfaces, so the limitation of 3 is not enough now. But just increase one is not future-proofed. Since the channel index type in gs_host_frame is u8, just make canch[] become a flexible array with a u8 index, so it naturally constraint by U8_MAX and avoid statically allocate 256 pointer for every gs_usb device. [1]: https://github.com/cherry-embedded/HSCanT-hardware Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Reported-by: Runcheng Lu <runcheng.lu(a)hpmicro.com> Cc: stable(a)vger.kernel.org Reviewed-by: Vincent Mailhol <mailhol(a)kernel.org> Signed-off-by: Celeste Liu <uwu(a)coelacanthus.name> Link: https://patch.msgid.link/20250930-gs-usb-max-if-v5-1-863330bf6666@coelacant… Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c index c9482d6e947b..9fb4cbbd6d6d 100644 --- a/drivers/net/can/usb/gs_usb.c +++ b/drivers/net/can/usb/gs_usb.c @@ -289,11 +289,6 @@ struct gs_host_frame { #define GS_MAX_RX_URBS 30 #define GS_NAPI_WEIGHT 32 -/* Maximum number of interfaces the driver supports per device. - * Current hardware only supports 3 interfaces. The future may vary. - */ -#define GS_MAX_INTF 3 - struct gs_tx_context { struct gs_can *dev; unsigned int echo_id; @@ -324,7 +319,6 @@ struct gs_can { /* usb interface struct */ struct gs_usb { - struct gs_can *canch[GS_MAX_INTF]; struct usb_anchor rx_submitted; struct usb_device *udev; @@ -336,9 +330,11 @@ struct gs_usb { unsigned int hf_size_rx; u8 active_channels; + u8 channel_cnt; unsigned int pipe_in; unsigned int pipe_out; + struct gs_can *canch[] __counted_by(channel_cnt); }; /* 'allocate' a tx context. @@ -599,7 +595,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb) } /* device reports out of range channel id */ - if (hf->channel >= GS_MAX_INTF) + if (hf->channel >= parent->channel_cnt) goto device_detach; dev = parent->canch[hf->channel]; @@ -699,7 +695,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb) /* USB failure take down all interfaces */ if (rc == -ENODEV) { device_detach: - for (rc = 0; rc < GS_MAX_INTF; rc++) { + for (rc = 0; rc < parent->channel_cnt; rc++) { if (parent->canch[rc]) netif_device_detach(parent->canch[rc]->netdev); } @@ -1460,17 +1456,19 @@ static int gs_usb_probe(struct usb_interface *intf, icount = dconf.icount + 1; dev_info(&intf->dev, "Configuring for %u interfaces\n", icount); - if (icount > GS_MAX_INTF) { + if (icount > type_max(parent->channel_cnt)) { dev_err(&intf->dev, "Driver cannot handle more that %u CAN interfaces\n", - GS_MAX_INTF); + type_max(parent->channel_cnt)); return -EINVAL; } - parent = kzalloc(sizeof(*parent), GFP_KERNEL); + parent = kzalloc(struct_size(parent, canch, icount), GFP_KERNEL); if (!parent) return -ENOMEM; + parent->channel_cnt = icount; + init_usb_anchor(&parent->rx_submitted); usb_set_intfdata(intf, parent); @@ -1531,7 +1529,7 @@ static void gs_usb_disconnect(struct usb_interface *intf) return; } - for (i = 0; i < GS_MAX_INTF; i++) + for (i = 0; i < parent->channel_cnt; i++) if (parent->canch[i]) gs_destroy_candev(parent->canch[i]);

1 week, 1 day

3
4
0 0

FAILED: patch "[PATCH] can: gs_usb: increase max interface to U8_MAX" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 2a27f6a8fb5722223d526843040f747e9b0e8060 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102038-outsource-awhile-6150@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2a27f6a8fb5722223d526843040f747e9b0e8060 Mon Sep 17 00:00:00 2001 From: Celeste Liu <uwu(a)coelacanthus.name> Date: Tue, 30 Sep 2025 19:34:28 +0800 Subject: [PATCH] can: gs_usb: increase max interface to U8_MAX This issue was found by Runcheng Lu when develop HSCanT USB to CAN FD converter[1]. The original developers may have only 3 interfaces device to test so they write 3 here and wait for future change. During the HSCanT development, we actually used 4 interfaces, so the limitation of 3 is not enough now. But just increase one is not future-proofed. Since the channel index type in gs_host_frame is u8, just make canch[] become a flexible array with a u8 index, so it naturally constraint by U8_MAX and avoid statically allocate 256 pointer for every gs_usb device. [1]: https://github.com/cherry-embedded/HSCanT-hardware Fixes: d08e973a77d1 ("can: gs_usb: Added support for the GS_USB CAN devices") Reported-by: Runcheng Lu <runcheng.lu(a)hpmicro.com> Cc: stable(a)vger.kernel.org Reviewed-by: Vincent Mailhol <mailhol(a)kernel.org> Signed-off-by: Celeste Liu <uwu(a)coelacanthus.name> Link: https://patch.msgid.link/20250930-gs-usb-max-if-v5-1-863330bf6666@coelacant… Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c index c9482d6e947b..9fb4cbbd6d6d 100644 --- a/drivers/net/can/usb/gs_usb.c +++ b/drivers/net/can/usb/gs_usb.c @@ -289,11 +289,6 @@ struct gs_host_frame { #define GS_MAX_RX_URBS 30 #define GS_NAPI_WEIGHT 32 -/* Maximum number of interfaces the driver supports per device. - * Current hardware only supports 3 interfaces. The future may vary. - */ -#define GS_MAX_INTF 3 - struct gs_tx_context { struct gs_can *dev; unsigned int echo_id; @@ -324,7 +319,6 @@ struct gs_can { /* usb interface struct */ struct gs_usb { - struct gs_can *canch[GS_MAX_INTF]; struct usb_anchor rx_submitted; struct usb_device *udev; @@ -336,9 +330,11 @@ struct gs_usb { unsigned int hf_size_rx; u8 active_channels; + u8 channel_cnt; unsigned int pipe_in; unsigned int pipe_out; + struct gs_can *canch[] __counted_by(channel_cnt); }; /* 'allocate' a tx context. @@ -599,7 +595,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb) } /* device reports out of range channel id */ - if (hf->channel >= GS_MAX_INTF) + if (hf->channel >= parent->channel_cnt) goto device_detach; dev = parent->canch[hf->channel]; @@ -699,7 +695,7 @@ static void gs_usb_receive_bulk_callback(struct urb *urb) /* USB failure take down all interfaces */ if (rc == -ENODEV) { device_detach: - for (rc = 0; rc < GS_MAX_INTF; rc++) { + for (rc = 0; rc < parent->channel_cnt; rc++) { if (parent->canch[rc]) netif_device_detach(parent->canch[rc]->netdev); } @@ -1460,17 +1456,19 @@ static int gs_usb_probe(struct usb_interface *intf, icount = dconf.icount + 1; dev_info(&intf->dev, "Configuring for %u interfaces\n", icount); - if (icount > GS_MAX_INTF) { + if (icount > type_max(parent->channel_cnt)) { dev_err(&intf->dev, "Driver cannot handle more that %u CAN interfaces\n", - GS_MAX_INTF); + type_max(parent->channel_cnt)); return -EINVAL; } - parent = kzalloc(sizeof(*parent), GFP_KERNEL); + parent = kzalloc(struct_size(parent, canch, icount), GFP_KERNEL); if (!parent) return -ENOMEM; + parent->channel_cnt = icount; + init_usb_anchor(&parent->rx_submitted); usb_set_intfdata(intf, parent); @@ -1531,7 +1529,7 @@ static void gs_usb_disconnect(struct usb_interface *intf) return; } - for (i = 0; i < GS_MAX_INTF; i++) + for (i = 0; i < parent->channel_cnt; i++) if (parent->canch[i]) gs_destroy_candev(parent->canch[i]);

1 week, 1 day

3
4
0 0

[PATCH wireless-next v3 1/4] wifi: cfg80211: add an hrtimer based delayed work item

by Miri Korenblit

From: Benjamin Berg <benjamin.berg(a)intel.com> The normal timer mechanism assume that timeout further in the future need a lower accuracy. As an example, the granularity for a timer scheduled 4096 ms in the future on a 1000 Hz system is already 512 ms. This granularity is perfectly sufficient for e.g. timeouts, but there are other types of events that will happen at a future point in time and require a higher accuracy. Add a new wiphy_hrtimer_work type that uses an hrtimer internally. The API is almost identical to the existing wiphy_delayed_work and it can be used as a drop-in replacement after minor adjustments. The work will be scheduled relative to the current time with a slack of 1 millisecond. CC: stable(a)vger.kernel.org # 6.4+ Signed-off-by: Benjamin Berg <benjamin.berg(a)intel.com> Reviewed-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit(a)intel.com> --- include/net/cfg80211.h | 78 ++++++++++++++++++++++++++++++++++++++++++ net/wireless/core.c | 56 ++++++++++++++++++++++++++++++ net/wireless/trace.h | 21 ++++++++++++ 3 files changed, 155 insertions(+) diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 53490eb04e87..f2e8963cfaac 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -6440,6 +6440,11 @@ static inline void wiphy_delayed_work_init(struct wiphy_delayed_work *dwork, * after wiphy_lock() was called. Therefore, wiphy_cancel_work() can * use just cancel_work() instead of cancel_work_sync(), it requires * being in a section protected by wiphy_lock(). + * + * Note that these are scheduled with a timer where the accuracy + * becomes less the longer in the future the scheduled timer is. Use + * wiphy_hrtimer_work_queue() if the timer must be not be late by more + * than approximately 10 percent. */ void wiphy_delayed_work_queue(struct wiphy *wiphy, struct wiphy_delayed_work *dwork, @@ -6511,6 +6516,79 @@ void wiphy_delayed_work_flush(struct wiphy *wiphy, bool wiphy_delayed_work_pending(struct wiphy *wiphy, struct wiphy_delayed_work *dwork); +struct wiphy_hrtimer_work { + struct wiphy_work work; + struct wiphy *wiphy; + struct hrtimer timer; +}; + +enum hrtimer_restart wiphy_hrtimer_work_timer(struct hrtimer *t); + +static inline void wiphy_hrtimer_work_init(struct wiphy_hrtimer_work *hrwork, + wiphy_work_func_t func) +{ + hrtimer_setup(&hrwork->timer, wiphy_hrtimer_work_timer, + CLOCK_BOOTTIME, HRTIMER_MODE_REL); + wiphy_work_init(&hrwork->work, func); +} + +/** + * wiphy_hrtimer_work_queue - queue hrtimer work for the wiphy + * @wiphy: the wiphy to queue for + * @hrwork: the high resolution timer worker + * @delay: the delay given as a ktime_t + * + * Please refer to wiphy_delayed_work_queue(). The difference is that + * the hrtimer work uses a high resolution timer for scheduling. This + * may be needed if timeouts might be scheduled further in the future + * and the accuracy of the normal timer is not sufficient. + * + * Expect a delay of a few milliseconds as the timer is scheduled + * with some slack and some more time may pass between queueing the + * work and its start. + */ +void wiphy_hrtimer_work_queue(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork, + ktime_t delay); + +/** + * wiphy_hrtimer_work_cancel - cancel previously queued hrtimer work + * @wiphy: the wiphy, for debug purposes + * @hrtimer: the hrtimer work to cancel + * + * Cancel the work *without* waiting for it, this assumes being + * called under the wiphy mutex acquired by wiphy_lock(). + */ +void wiphy_hrtimer_work_cancel(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrtimer); + +/** + * wiphy_hrtimer_work_flush - flush previously queued hrtimer work + * @wiphy: the wiphy, for debug purposes + * @hrwork: the hrtimer work to flush + * + * Flush the work (i.e. run it if pending). This must be called + * under the wiphy mutex acquired by wiphy_lock(). + */ +void wiphy_hrtimer_work_flush(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork); + +/** + * wiphy_hrtimer_work_pending - Find out whether a wiphy hrtimer + * work item is currently pending. + * + * @wiphy: the wiphy, for debug purposes + * @hrwork: the hrtimer work in question + * + * Return: true if timer is pending, false otherwise + * + * Please refer to the wiphy_delayed_work_pending() documentation as + * this is the equivalent function for hrtimer based delayed work + * items. + */ +bool wiphy_hrtimer_work_pending(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork); + /** * enum ieee80211_ap_reg_power - regulatory power for an Access Point * diff --git a/net/wireless/core.c b/net/wireless/core.c index f3568eb5e592..9f858a83e912 100644 --- a/net/wireless/core.c +++ b/net/wireless/core.c @@ -1802,6 +1802,62 @@ bool wiphy_delayed_work_pending(struct wiphy *wiphy, } EXPORT_SYMBOL_GPL(wiphy_delayed_work_pending); +enum hrtimer_restart wiphy_hrtimer_work_timer(struct hrtimer *t) +{ + struct wiphy_hrtimer_work *hrwork = + container_of(t, struct wiphy_hrtimer_work, timer); + + wiphy_work_queue(hrwork->wiphy, &hrwork->work); + + return HRTIMER_NORESTART; +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_timer); + +void wiphy_hrtimer_work_queue(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork, + ktime_t delay) +{ + trace_wiphy_hrtimer_work_queue(wiphy, &hrwork->work, delay); + + if (!delay) { + hrtimer_cancel(&hrwork->timer); + wiphy_work_queue(wiphy, &hrwork->work); + return; + } + + hrwork->wiphy = wiphy; + hrtimer_start_range_ns(&hrwork->timer, delay, + 1000 * NSEC_PER_USEC, HRTIMER_MODE_REL); +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_queue); + +void wiphy_hrtimer_work_cancel(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork) +{ + lockdep_assert_held(&wiphy->mtx); + + hrtimer_cancel(&hrwork->timer); + wiphy_work_cancel(wiphy, &hrwork->work); +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_cancel); + +void wiphy_hrtimer_work_flush(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork) +{ + lockdep_assert_held(&wiphy->mtx); + + hrtimer_cancel(&hrwork->timer); + wiphy_work_flush(wiphy, &hrwork->work); +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_flush); + +bool wiphy_hrtimer_work_pending(struct wiphy *wiphy, + struct wiphy_hrtimer_work *hrwork) +{ + return hrtimer_is_queued(&hrwork->timer); +} +EXPORT_SYMBOL_GPL(wiphy_hrtimer_work_pending); + static int __init cfg80211_init(void) { int err; diff --git a/net/wireless/trace.h b/net/wireless/trace.h index 8a4c34112eb5..2b71f1d867a0 100644 --- a/net/wireless/trace.h +++ b/net/wireless/trace.h @@ -304,6 +304,27 @@ TRACE_EVENT(wiphy_delayed_work_queue, __entry->delay) ); +TRACE_EVENT(wiphy_hrtimer_work_queue, + TP_PROTO(struct wiphy *wiphy, struct wiphy_work *work, + ktime_t delay), + TP_ARGS(wiphy, work, delay), + TP_STRUCT__entry( + WIPHY_ENTRY + __field(void *, instance) + __field(void *, func) + __field(ktime_t, delay) + ), + TP_fast_assign( + WIPHY_ASSIGN; + __entry->instance = work; + __entry->func = work->func; + __entry->delay = delay; + ), + TP_printk(WIPHY_PR_FMT " instance=%p func=%pS delay=%llu", + WIPHY_PR_ARG, __entry->instance, __entry->func, + __entry->delay) +); + TRACE_EVENT(wiphy_work_worker_start, TP_PROTO(struct wiphy *wiphy), TP_ARGS(wiphy), -- 2.34.1

1 week, 1 day

1
0
0 0

[PATCH] s390/mm: Fix memory leak in add_marker() when kvrealloc fails

by Miaoqian Lin

When kvrealloc() fails, the original markers memory is leaked because the function directly assigns the NULL to the markers pointer, losing the reference to the original memory. As a result, the kvfree() in pt_dump_init() ends up freeing NULL instead of the previously allocated memory. Fix this by using a temporary variable to store kvrealloc()'s return value and only update the markers pointer on success. Found via static anlaysis and this is similar to commit 42378a9ca553 ("bpf, verifier: Fix memory leak in array reallocation for stack state") Fixes: d0e7915d2ad3 ("s390/mm/ptdump: Generate address marker array dynamically") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- arch/s390/mm/dump_pagetables.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/arch/s390/mm/dump_pagetables.c b/arch/s390/mm/dump_pagetables.c index 9af2aae0a515..0f2e0c93a1e0 100644 --- a/arch/s390/mm/dump_pagetables.c +++ b/arch/s390/mm/dump_pagetables.c @@ -291,16 +291,19 @@ static int ptdump_cmp(const void *a, const void *b) static int add_marker(unsigned long start, unsigned long end, const char *name) { + struct addr_marker *new_markers; size_t oldsize, newsize; oldsize = markers_cnt * sizeof(*markers); newsize = oldsize + 2 * sizeof(*markers); if (!oldsize) - markers = kvmalloc(newsize, GFP_KERNEL); + new_markers = kvmalloc(newsize, GFP_KERNEL); else - markers = kvrealloc(markers, newsize, GFP_KERNEL); - if (!markers) + new_markers = kvrealloc(markers, newsize, GFP_KERNEL); + if (!new_markers) goto error; + + markers = new_markers; markers[markers_cnt].is_start = 1; markers[markers_cnt].start_address = start; markers[markers_cnt].size = end - start; -- 2.39.5 (Apple Git-154)

1 week, 1 day

3
3
0 0

[PATCH] dma-fence: Fix safe access wrapper to call timeline name method

by Akash Goel

This commit fixes the wrapper function dma_fence_timeline_name(), that was added for safe access, to actually call the timeline name method of dma_fence_ops. Cc: <stable(a)vger.kernel.org> # v6.17+ Signed-off-by: Akash Goel <akash.goel(a)arm.com> --- drivers/dma-buf/dma-fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index 3f78c56b58dc..39e6f93dc310 100644 --- a/drivers/dma-buf/dma-fence.c +++ b/drivers/dma-buf/dma-fence.c @@ -1141,7 +1141,7 @@ const char __rcu *dma_fence_timeline_name(struct dma_fence *fence) "RCU protection is required for safe access to returned string"); if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags)) - return fence->ops->get_driver_name(fence); + return fence->ops->get_timeline_name(fence); else return "signaled-timeline"; } -- 2.25.1

1 week, 1 day

3
2
0 0

FAILED: patch "[PATCH] vsock: fix lock inversion in vsock_assign_transport()" failed to apply to 5.10-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.10-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y git checkout FETCH_HEAD git cherry-pick -x f7c877e7535260cc7a21484c994e8ce7e8cb6780 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025102616-navy-creatable-7fad@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f7c877e7535260cc7a21484c994e8ce7e8cb6780 Mon Sep 17 00:00:00 2001 From: Stefano Garzarella <sgarzare(a)redhat.com> Date: Tue, 21 Oct 2025 14:17:18 +0200 Subject: [PATCH] vsock: fix lock inversion in vsock_assign_transport() Syzbot reported a potential lock inversion deadlock between vsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called. The issue was introduced by commit 687aa0c5581b ("vsock: Fix transport_* TOCTOU") which added vsock_register_mutex locking in vsock_assign_transport() around the transport->release() call, that can call vsock_linger(). vsock_assign_transport() can be called with sk_lock held. vsock_linger() calls sk_wait_event() that temporarily releases and re-acquires sk_lock. During this window, if another thread hold vsock_register_mutex while trying to acquire sk_lock, a circular dependency is created. Fix this by releasing vsock_register_mutex before calling transport->release() and vsock_deassign_transport(). This is safe because we don't need to hold vsock_register_mutex while releasing the old transport, and we ensure the new transport won't disappear by obtaining a module reference first via try_module_get(). Reported-by: syzbot+10e35716f8e4929681fa(a)syzkaller.appspotmail.com Tested-by: syzbot+10e35716f8e4929681fa(a)syzkaller.appspotmail.com Fixes: 687aa0c5581b ("vsock: Fix transport_* TOCTOU") Cc: mhal(a)rbox.co Cc: stable(a)vger.kernel.org Signed-off-by: Stefano Garzarella <sgarzare(a)redhat.com> Link: https://patch.msgid.link/20251021121718.137668-1-sgarzare@redhat.com Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c index 4c2db6cca557..76763247a377 100644 --- a/net/vmw_vsock/af_vsock.c +++ b/net/vmw_vsock/af_vsock.c @@ -487,12 +487,26 @@ int vsock_assign_transport(struct vsock_sock *vsk, struct vsock_sock *psk) goto err; } - if (vsk->transport) { - if (vsk->transport == new_transport) { - ret = 0; - goto err; - } + if (vsk->transport && vsk->transport == new_transport) { + ret = 0; + goto err; + } + /* We increase the module refcnt to prevent the transport unloading + * while there are open sockets assigned to it. + */ + if (!new_transport || !try_module_get(new_transport->module)) { + ret = -ENODEV; + goto err; + } + + /* It's safe to release the mutex after a successful try_module_get(). + * Whichever transport `new_transport` points at, it won't go away until + * the last module_put() below or in vsock_deassign_transport(). + */ + mutex_unlock(&vsock_register_mutex); + + if (vsk->transport) { /* transport->release() must be called with sock lock acquired. * This path can only be taken during vsock_connect(), where we * have already held the sock lock. In the other cases, this @@ -512,20 +526,6 @@ int vsock_assign_transport(struct vsock_sock *vsk, struct vsock_sock *psk) vsk->peer_shutdown = 0; } - /* We increase the module refcnt to prevent the transport unloading - * while there are open sockets assigned to it. - */ - if (!new_transport || !try_module_get(new_transport->module)) { - ret = -ENODEV; - goto err; - } - - /* It's safe to release the mutex after a successful try_module_get(). - * Whichever transport `new_transport` points at, it won't go away until - * the last module_put() below or in vsock_deassign_transport(). - */ - mutex_unlock(&vsock_register_mutex); - if (sk->sk_type == SOCK_SEQPACKET) { if (!new_transport->seqpacket_allow || !new_transport->seqpacket_allow(remote_cid)) {

1 week, 1 day

2
1
0 0

[REGRESSION] 6.16 fae58d0155 prevents boot of google-tomato (mt8195)

by ninelore

Hi, starting with the bisected commit fae58d0155a979a8c414bbc12db09dd4b2f910d0 ("[v2] drm/mediatek: Fix device/node reference count leaks in mtk_drm_get_all_drm_priv") on 6.16.y my chromebook codenamed google-tomato with the SoC MT8195 seems to hang while initializing drm. Kernel messages over serial show CPU stalls some minutes later. I am attaching the full kernel logs below. This issue is present in 6.16.7, however not in v6.17-rc6 This is my first time reporting a bug here. Please let me know if you need additional information. Thanks and kind regards Ingo Reitz -------- Booting Linux on physical CPU 0x0000000000 [0x412fd050] Linux version 6.16.4 (nixbld@localhost) (aarch64-unknown-linux-gnu-gcc (GCC) 14.3.0, GNU ld (GNU Binutils) 2.44) #1-NixOS SMP Tue Jan 1 00:00:00 UTC 1980 Machine model: Acer Tomato (rev3 - 4) board Reserved memory: created DMA memory pool at 0x0000000050000000, size 41 MiB OF: reserved mem: initialized node memory@50000000, compatible id shared-dma-pool OF: reserved mem: 0x0000000050000000..0x00000000528fffff (41984 KiB) nomap non-reusable memory@50000000 Reserved memory: created DMA memory pool at 0x0000000060000000, size 13 MiB OF: reserved mem: initialized node memory@60000000, compatible id shared-dma-pool OF: reserved mem: 0x0000000060000000..0x0000000060d7ffff (13824 KiB) nomap non-reusable memory@60000000 Reserved memory: created DMA memory pool at 0x0000000060d80000, size 1 MiB OF: reserved mem: initialized node memory@60d80000, compatible id shared-dma-pool OF: reserved mem: 0x0000000060d80000..0x0000000060e7ffff (1024 KiB) nomap non-reusable memory@60d80000 Reserved memory: created DMA memory pool at 0x0000000060e80000, size 2 MiB OF: reserved mem: initialized node memory@60e80000, compatible id shared-dma-pool OF: reserved mem: 0x0000000060e80000..0x00000000610fffff (2560 KiB) nomap non-reusable memory@60e80000 Zone ranges: Normal [mem 0x0000000040000000-0x000000023fffffff] Movable zone start for each node Early memory node ranges node 0: [mem 0x0000000040000000-0x000000004fffffff] node 0: [mem 0x0000000050000000-0x00000000528fffff] node 0: [mem 0x0000000052900000-0x00000000545fffff] node 0: [mem 0x0000000054660000-0x000000005fffffff] node 0: [mem 0x0000000060000000-0x00000000610fffff] node 0: [mem 0x0000000061100000-0x00000000fffdafff] node 0: [mem 0x0000000100000000-0x000000023fffffff] Initmem setup node 0 [mem 0x0000000040000000-0x000000023fffffff] On node 0, zone Normal: 96 pages in unavailable ranges On node 0, zone Normal: 37 pages in unavailable ranges psci: probing for conduit method from DT. psci: PSCIv1.1 detected in firmware. psci: Using standard PSCI v0.2 function IDs psci: MIGRATE_INFO_TYPE not supported. psci: SMC Calling Convention v1.5 percpu: Embedded 17 pages/cpu s40608 r0 d29024 u69632 pcpu-alloc: s40608 r0 d29024 u69632 alloc=17*4096 pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7 Detected VIPT I-cache on CPU0 CPU features: detected: GIC system register CPU interface CPU features: detected: Virtualization Host Extensions CPU features: kernel page table isolation disabled by kernel configuration alternatives: applying boot alternatives Kernel command line: console=tty0 console=ttyS0,115200n8 loglevel=15 printk: log buffer data + meta data: 131072 + 458752 = 589824 bytes Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes, linear) Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes, linear) software IO TLB: SWIOTLB bounce buffer size adjusted to 8MB software IO TLB: area num 8. software IO TLB: mapped [mem 0x0000000236a00000-0x0000000237200000] (8MB) Built 1 zonelists, mobility grouping on. Total pages: 2097019 mem auto-init: stack:all(zero), heap alloc:off, heap free:off SLUB: HWalign=64, Order=0-1, MinObjects=0, CPUs=8, Nodes=1 rcu: Hierarchical RCU implementation. rcu: RCU restricting CPUs from NR_CPUS=512 to nr_cpu_ids=8. rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies. rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=8 NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0 GICv3: GIC: Using split EOI/Deactivate mode GICv3: 864 SPIs implemented GICv3: 0 Extended SPIs implemented Root IRQ handler: 0xffff80008001007c GICv3: GICv3 features: 16 PPIs GICv3: GICD_CTRL.DS=0, SCR_EL3.FIQ=0 GICv3: CPU0: found redistributor 0 region 0:0x000000000c040000 GICv3: GIC: PPI partition interrupt-partition-0[0] { /cpus/cpu@0[0] /cpus/cpu@100[1] /cpus/cpu@200[2] /cpus/cpu@300[3] } GICv3: GIC: PPI partition interrupt-partition-1[1] { /cpus/cpu@400[4] /cpus/cpu@500[5] /cpus/cpu@600[6] /cpus/cpu@700[7] } rcu: srcu_init: Setting srcu_struct sizes based on contention. arch_timer: cp15 timer(s) running at 13.00MHz (phys). clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x2ff89eacb, max_idle_ns: 440795202429 ns sched_clock: 56 bits at 13MHz, resolution 76ns, wraps every 4398046511101ns Console: colour dummy device 80x25 printk: legacy console [tty0] enabled Calibrating delay loop (skipped), value calculated using timer frequency.. 26.00 BogoMIPS (lpj=52000) pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 16384 (order: 5, 131072 bytes, linear) Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes, linear) rcu: Hierarchical SRCU implementation. rcu: Max phase no-delay instances is 1000. smp: Bringing up secondary CPUs ... Detected VIPT I-cache on CPU1 GICv3: CPU1: found redistributor 100 region 0:0x000000000c060000 CPU1: Booted secondary processor 0x0000000100 [0x412fd050] Detected VIPT I-cache on CPU2 GICv3: CPU2: found redistributor 200 region 0:0x000000000c080000 CPU2: Booted secondary processor 0x0000000200 [0x412fd050] Detected VIPT I-cache on CPU3 GICv3: CPU3: found redistributor 300 region 0:0x000000000c0a0000 CPU3: Booted secondary processor 0x0000000300 [0x412fd050] CPU features: detected: Spectre-v4 CPU features: detected: Spectre-BHB Detected PIPT I-cache on CPU4 GICv3: CPU4: found redistributor 400 region 0:0x000000000c0c0000 CPU4: Booted secondary processor 0x0000000400 [0x411fd410] Detected PIPT I-cache on CPU5 GICv3: CPU5: found redistributor 500 region 0:0x000000000c0e0000 CPU5: Booted secondary processor 0x0000000500 [0x411fd410] Detected PIPT I-cache on CPU6 GICv3: CPU6: found redistributor 600 region 0:0x000000000c100000 CPU6: Booted secondary processor 0x0000000600 [0x411fd410] Detected PIPT I-cache on CPU7 GICv3: CPU7: found redistributor 700 region 0:0x000000000c120000 CPU7: Booted secondary processor 0x0000000700 [0x411fd410] smp: Brought up 1 node, 8 CPUs SMP: Total of 8 processors activated. CPU: All CPU(s) started at EL2 CPU features: detected: 32-bit EL0 Support CPU features: detected: Data cache clean to the PoU not required for I/D coherence CPU features: detected: Common not Private translations CPU features: detected: CRC32 instructions CPU features: detected: Data cache clean to Point of Persistence CPU features: detected: RCpc load-acquire (LDAPR) CPU features: detected: LSE atomic instructions CPU features: detected: PMUv3 CPU features: detected: RAS Extension Support CPU features: detected: Speculative Store Bypassing Safe (SSBS) spectre-bhb mitigation disabled by compile time option spectre-bhb mitigation disabled by compile time option alternatives: applying system-wide alternatives CPU features: detected: Hardware dirty bit management on CPU0-7 Memory: 8159184K/8388076K available (4928K kernel code, 924K rwdata, 1800K rodata, 896K init, 479K bss, 224752K reserved, 0K cma-reserved) devtmpfs: initialized clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns futex hash table entries: 2048 (131072 bytes on 1 NUMA nodes, total 128 KiB, linear). pinctrl core: initialized pinctrl subsystem DMA: preallocated 1024 KiB GFP_KERNEL pool for atomic allocations thermal_sys: Registered thermal governor 'step_wise' thermal_sys: Registered thermal governor 'power_allocator' hw-breakpoint: found 6 breakpoint and 4 watchpoint registers. ASID allocator initialised with 65536 entries Serial: AMBA PL011 UART driver /soc/interrupt-controller@c000000: Fixed dependency cycle(s) with /soc/interrupt-controller@c000000 /soc/syscon@1c01a000: Fixed dependency cycle(s) with /soc/ovl@1c000000 /soc/ovl@1c000000: Fixed dependency cycle(s) with /soc/rdma@1c002000 /soc/ovl@1c000000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/rdma@1c002000: Fixed dependency cycle(s) with /soc/color@1c003000 /soc/rdma@1c002000: Fixed dependency cycle(s) with /soc/ovl@1c000000 /soc/rdma@1c002000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/color@1c003000: Fixed dependency cycle(s) with /soc/ccorr@1c004000 /soc/color@1c003000: Fixed dependency cycle(s) with /soc/rdma@1c002000 /soc/color@1c003000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/ccorr@1c004000: Fixed dependency cycle(s) with /soc/aal@1c005000 /soc/ccorr@1c004000: Fixed dependency cycle(s) with /soc/color@1c003000 /soc/ccorr@1c004000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/aal@1c005000: Fixed dependency cycle(s) with /soc/gamma@1c006000 /soc/aal@1c005000: Fixed dependency cycle(s) with /soc/ccorr@1c004000 /soc/aal@1c005000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/gamma@1c006000: Fixed dependency cycle(s) with /soc/dither@1c007000 /soc/gamma@1c006000: Fixed dependency cycle(s) with /soc/aal@1c005000 /soc/gamma@1c006000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/dither@1c007000: Fixed dependency cycle(s) with /soc/dsc@1c009000 /soc/dither@1c007000: Fixed dependency cycle(s) with /soc/gamma@1c006000 /soc/dither@1c007000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/dsc@1c009000: Fixed dependency cycle(s) with /soc/merge@1c014000 /soc/dsc@1c009000: Fixed dependency cycle(s) with /soc/dither@1c007000 /soc/dsc@1c009000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/merge@1c014000: Fixed dependency cycle(s) with /soc/dp-intf@1c015000 /soc/merge@1c014000: Fixed dependency cycle(s) with /soc/dsc@1c009000 /soc/merge@1c014000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/dp-intf@1c015000: Fixed dependency cycle(s) with /soc/edp-tx@1c500000 /soc/dp-intf@1c015000: Fixed dependency cycle(s) with /soc/merge@1c014000 /soc/dp-intf@1c015000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/syscon@1c100000: Fixed dependency cycle(s) with /soc/hdr-engine@1c114000 /soc/vpp-merge@1c110000: Fixed dependency cycle(s) with /soc/dp-intf@1c113000 /soc/vpp-merge@1c110000: Fixed dependency cycle(s) with /soc/hdr-engine@1c114000 /soc/vpp-merge@1c110000: Fixed dependency cycle(s) with /soc/syscon@1c100000 /soc/dp-intf@1c113000: Fixed dependency cycle(s) with /soc/dp-tx@1c600000 /soc/dp-intf@1c113000: Fixed dependency cycle(s) with /soc/vpp-merge@1c110000 /soc/dp-intf@1c113000: Fixed dependency cycle(s) with /soc/syscon@1c100000 /soc/hdr-engine@1c114000: Fixed dependency cycle(s) with /soc/vpp-merge@1c110000 /soc/hdr-engine@1c114000: Fixed dependency cycle(s) with /soc/syscon@1c100000 /soc/edp-tx@1c500000: Fixed dependency cycle(s) with /soc/edp-tx@1c500000/aux-bus/panel /soc/edp-tx@1c500000: Fixed dependency cycle(s) with /soc/dp-intf@1c015000 /soc/edp-tx@1c500000/aux-bus/panel: Fixed dependency cycle(s) with /soc/edp-tx@1c500000 /soc/dp-tx@1c600000: Fixed dependency cycle(s) with /soc/dp-intf@1c113000 /soc/pinctrl@10005000: Fixed dependency cycle(s) with /soc/pinctrl@10005000/pio-default-pins /soc/pcie@112f8000: Fixed dependency cycle(s) with /soc/pcie@112f8000/interrupt-controller /soc/syscon@1c01a000: Fixed dependency cycle(s) with /soc/ovl@1c000000 /soc/syscon@1c01a000: Fixed dependency cycle(s) with /soc/ovl@1c000000 /soc/ovl@1c000000: Fixed dependency cycle(s) with /soc/rdma@1c002000 /soc/ovl@1c000000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/ovl@1c000000: Fixed dependency cycle(s) with /soc/rdma@1c002000 /soc/rdma@1c002000: Fixed dependency cycle(s) with /soc/color@1c003000 /soc/rdma@1c002000: Fixed dependency cycle(s) with /soc/ovl@1c000000 /soc/rdma@1c002000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/rdma@1c002000: Fixed dependency cycle(s) with /soc/color@1c003000 /soc/color@1c003000: Fixed dependency cycle(s) with /soc/ccorr@1c004000 /soc/color@1c003000: Fixed dependency cycle(s) with /soc/rdma@1c002000 /soc/color@1c003000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/color@1c003000: Fixed dependency cycle(s) with /soc/ccorr@1c004000 /soc/ccorr@1c004000: Fixed dependency cycle(s) with /soc/aal@1c005000 /soc/ccorr@1c004000: Fixed dependency cycle(s) with /soc/color@1c003000 /soc/ccorr@1c004000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/ccorr@1c004000: Fixed dependency cycle(s) with /soc/aal@1c005000 /soc/aal@1c005000: Fixed dependency cycle(s) with /soc/gamma@1c006000 /soc/aal@1c005000: Fixed dependency cycle(s) with /soc/ccorr@1c004000 /soc/aal@1c005000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/aal@1c005000: Fixed dependency cycle(s) with /soc/gamma@1c006000 /soc/gamma@1c006000: Fixed dependency cycle(s) with /soc/dither@1c007000 /soc/gamma@1c006000: Fixed dependency cycle(s) with /soc/aal@1c005000 /soc/gamma@1c006000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/gamma@1c006000: Fixed dependency cycle(s) with /soc/dither@1c007000 /soc/dither@1c007000: Fixed dependency cycle(s) with /soc/dsc@1c009000 /soc/dither@1c007000: Fixed dependency cycle(s) with /soc/gamma@1c006000 /soc/dither@1c007000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/dither@1c007000: Fixed dependency cycle(s) with /soc/dsc@1c009000 /soc/dsc@1c009000: Fixed dependency cycle(s) with /soc/merge@1c014000 /soc/dsc@1c009000: Fixed dependency cycle(s) with /soc/dither@1c007000 /soc/dsc@1c009000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/dsc@1c009000: Fixed dependency cycle(s) with /soc/merge@1c014000 /soc/merge@1c014000: Fixed dependency cycle(s) with /soc/dp-intf@1c015000 /soc/merge@1c014000: Fixed dependency cycle(s) with /soc/dsc@1c009000 /soc/merge@1c014000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/merge@1c014000: Fixed dependency cycle(s) with /soc/dp-intf@1c015000 /soc/dp-intf@1c015000: Fixed dependency cycle(s) with /soc/edp-tx@1c500000 /soc/dp-intf@1c015000: Fixed dependency cycle(s) with /soc/merge@1c014000 /soc/dp-intf@1c015000: Fixed dependency cycle(s) with /soc/syscon@1c01a000 /soc/syscon@1c100000: Fixed dependency cycle(s) with /soc/hdr-engine@1c114000 /soc/vpp-merge@1c110000: Fixed dependency cycle(s) with /soc/dp-intf@1c113000 /soc/vpp-merge@1c110000: Fixed dependency cycle(s) with /soc/hdr-engine@1c114000 /soc/vpp-merge@1c110000: Fixed dependency cycle(s) with /soc/syscon@1c100000 /soc/vpp-merge@1c110000: Fixed dependency cycle(s) with /soc/dp-intf@1c113000 /soc/dp-intf@1c113000: Fixed dependency cycle(s) with /soc/dp-tx@1c600000 /soc/dp-intf@1c113000: Fixed dependency cycle(s) with /soc/vpp-merge@1c110000 /soc/dp-intf@1c113000: Fixed dependency cycle(s) with /soc/syscon@1c100000 /soc/vpp-merge@1c110000: Fixed dependency cycle(s) with /soc/hdr-engine@1c114000 /soc/syscon@1c100000: Fixed dependency cycle(s) with /soc/hdr-engine@1c114000 /soc/hdr-engine@1c114000: Fixed dependency cycle(s) with /soc/vpp-merge@1c110000 /soc/hdr-engine@1c114000: Fixed dependency cycle(s) with /soc/syscon@1c100000 /soc/dp-intf@1c015000: Fixed dependency cycle(s) with /soc/edp-tx@1c500000 /soc/edp-tx@1c500000: Fixed dependency cycle(s) with /soc/edp-tx@1c500000/aux-bus/panel /soc/edp-tx@1c500000: Fixed dependency cycle(s) with /soc/dp-intf@1c015000 /soc/edp-tx@1c500000/aux-bus/panel: Fixed dependency cycle(s) with /soc/edp-tx@1c500000 /soc/dp-intf@1c113000: Fixed dependency cycle(s) with /soc/dp-tx@1c600000 /soc/dp-tx@1c600000: Fixed dependency cycle(s) with /soc/dp-intf@1c113000 HugeTLB: allocation took 0ms with hugepage_allocation_threads=2 HugeTLB: allocation took 0ms with hugepage_allocation_threads=2 HugeTLB: registered 1.00 GiB page size, pre-allocated 0 pages HugeTLB: 0 KiB vmemmap can be freed for a 1.00 GiB page HugeTLB: registered 32.0 MiB page size, pre-allocated 0 pages HugeTLB: 0 KiB vmemmap can be freed for a 32.0 MiB page HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages HugeTLB: 0 KiB vmemmap can be freed for a 2.00 MiB page HugeTLB: registered 64.0 KiB page size, pre-allocated 0 pages HugeTLB: 0 KiB vmemmap can be freed for a 64.0 KiB page iommu: Default domain type: Translated iommu: DMA domain TLB invalidation policy: strict mode SCSI subsystem initialized libata version 3.00 loaded. usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb vgaarb: loaded clocksource: Switched to clocksource arch_sys_counter PCI: CLS 0 bytes, default 64 Unpacking initramfs... workingset: timestamp_bits=62 max_order=21 bucket_order=0 squashfs: version 4.0 (2009/01/31) Phillip Lougher Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251) io scheduler mq-deadline registered io scheduler kyber registered io scheduler bfq registered Freeing initrd memory: 2996K cannot find "mediatek,mt8195-fhctl" mtk-socinfo mtk-socinfo.0.auto: MediaTek Kompanio 1380 (MT8195) SoC detected. Serial: 8250/16550 driver, 32 ports, IRQ sharing disabled printk: legacy console [ttyS0] disabled 11001100.serial: ttyS0 at MMIO 0x11001100 (irq = 253, base_baud = 1625000) is a ST16650V2 printk: legacy console [ttyS0] enabled Serial: AMBA driver loop: module loaded mt6359-keys: Failed to locate of_node [id: -1] mt6359-accdet: Failed to locate of_node [id: -1] mtk-spi-nor 1132c000.spi: spi frequency: 52000000 Hz usbcore: registered new interface driver usb-storage mt6397-rtc mt6359-rtc: registered as rtc0 mt6397-rtc mt6359-rtc: setting system clock to 2025-09-15T22:15:30 UTC (1757974530) mtk-lvts-thermal 1100b000.thermal-sensor: golden temp=60 vgpu11_sshub: Bringing 400000uV into 550000-550000uV thermal thermal_zone0: power_allocator: sustainable_power will be estimated thermal thermal_zone1: power_allocator: sustainable_power will be estimated thermal thermal_zone2: power_allocator: sustainable_power will be estimated thermal thermal_zone3: power_allocator: sustainable_power will be estimated thermal thermal_zone4: power_allocator: sustainable_power will be estimated thermal thermal_zone5: power_allocator: sustainable_power will be estimated thermal thermal_zone6: power_allocator: sustainable_power will be estimated thermal thermal_zone7: power_allocator: sustainable_power will be estimated thermal thermal_zone8: power_allocator: sustainable_power will be estimated mtk-lvts-thermal 11278000.thermal-sensor: golden temp=60 thermal thermal_zone9: power_allocator: sustainable_power will be estimated thermal thermal_zone10: power_allocator: sustainable_power will be estimated thermal thermal_zone11: power_allocator: sustainable_power will be estimated thermal thermal_zone12: power_allocator: sustainable_power will be estimated thermal thermal_zone13: power_allocator: sustainable_power will be estimated thermal thermal_zone14: power_allocator: sustainable_power will be estimated thermal thermal_zone15: power_allocator: sustainable_power will be estimated thermal thermal_zone16: power_allocator: sustainable_power will be estimated cpu cpu0: EM: created perf domain cpu cpu4: EM: created perf domain coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22 hid: raw HID events driver (C) Jiri Kosina usbcore: registered new interface driver usbhid usbhid: USB HID core driver spi_master spi0: will run message pump with realtime priority hw perfevents: enabled with armv8_cortex_a55 PMU driver, 7 (0,8000003f) counters available hw perfevents: enabled with armv8_cortex_a78 PMU driver, 7 (0,8000003f) counters available mediatek-drm mediatek-drm.12.auto: Adding component match for /soc/ovl@1c000000 mediatek-drm mediatek-drm.12.auto: Adding component match for /soc/rdma@1c002000 mediatek-drm mediatek-drm.12.auto: Adding component match for /soc/color@1c003000 mediatek-drm mediatek-drm.12.auto: Adding component match for /soc/ccorr@1c004000 mediatek-drm mediatek-drm.12.auto: Adding component match for /soc/aal@1c005000 mediatek-drm mediatek-drm.12.auto: Adding component match for /soc/gamma@1c006000 mediatek-drm mediatek-drm.12.auto: Adding component match for /soc/merge@1c014000 mediatek-drm mediatek-drm.12.auto: Adding component match for /soc/dp-intf@1c015000 mediatek-disp-ovl-adaptor mediatek-disp-ovl-adaptor.15.auto: Failed to get id. type: 2, alias: -19 mediatek-disp-ovl-adaptor mediatek-disp-ovl-adaptor.15.auto: Skipping unknown component /soc/merge@1c014000 mediatek-disp-ovl-adaptor mediatek-disp-ovl-adaptor.15.auto: Failed to get id. type: 2, alias: 5 mediatek-disp-ovl-adaptor mediatek-disp-ovl-adaptor.15.auto: Skipping unknown component /soc/vpp-merge@1c110000 mediatek-drm mediatek-drm.14.auto: Adding component match for /soc/vpp-merge@1c110000 mediatek-drm mediatek-drm.14.auto: Adding component match for /soc/dp-intf@1c113000 mtk-msdc 11230000.mmc: Final PAD_DS_TUNE: 0x15011 mtk-power-controller 10006000.syscon:power-controller: /soc/syscon@10006000/power-controller/power-domain@15/power-domain@16/power-domain@18/power-domain@20: A default off power domain has been ON input: cros_ec as /devices/platform/soc/1100a000.spi/spi_master/spi0/spi0.0/1100a000.spi:ec@0:keyboard-controller/input/input0 mmc0: Host Software Queue enabled mmc0: new HS400 MMC card at address 0001 mmcblk0: mmc0:0001 DA4128 116 GiB mmcblk0: p1 p2 p3 mmcblk0boot0: mmc0:0001 DA4128 4.00 MiB mmcblk0boot1: mmc0:0001 DA4128 4.00 MiB mmcblk0rpmb: mmc0:0001 DA4128 16.0 MiB, chardev (249:0) input: cros_ec_buttons as /devices/platform/soc/1100a000.spi/spi_master/spi0/spi0.0/1100a000.spi:ec@0:keyboard-controller/input/input1 /soc/edp-tx@1c500000: Fixed dependency cycle(s) with /soc/edp-tx@1c500000/aux-bus/panel /soc/edp-tx@1c500000/aux-bus/panel: Fixed dependency cycle(s) with /soc/edp-tx@1c500000 cros-ec-spi spi0.0: Chrome EC device registered mtu3 11201000.usb: uwk - reg:0x400, version:103 mtu3 11201000.usb: dr_mode: 1, drd: auto mtu3 11201000.usb: u2p_dis_msk: 0, u3p_dis_msk: 0 mtu3 11201000.usb: usb3-drd: 1 xhci-mtk 11200000.usb: supply vusb33 not found, using dummy regulator xhci-mtk 11200000.usb: xHCI Host Controller xhci-mtk 11200000.usb: new USB bus registered, assigned bus number 1 xhci-mtk 11200000.usb: hcc params 0x01400f99 hci version 0x110 quirks 0x0000000000200010 xhci-mtk 11200000.usb: irq 287, io mem 0x11200000 xhci-mtk 11200000.usb: xHCI Host Controller xhci-mtk 11200000.usb: new USB bus registered, assigned bus number 2 xhci-mtk 11200000.usb: Host supports USB 3.2 Enhanced SuperSpeed usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.16 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: xHCI Host Controller usb usb1: Manufacturer: Linux 6.16.4 xhci-hcd usb usb1: SerialNumber: 11200000.usb hub 1-0:1.0: USB hub found hub 1-0:1.0: 1 port detected usb usb2: We don't know the algorithms for LPM for this host, disabling LPM. usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.16 usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb2: Product: xHCI Host Controller usb usb2: Manufacturer: Linux 6.16.4 xhci-hcd usb usb2: SerialNumber: 11200000.usb hub 2-0:1.0: USB hub found hub 2-0:1.0: 1 port detected mtu3 11201000.usb: xHCI platform device register success... mtu3 112a1000.usb: uwk - reg:0x400, version:105 mtu3 112a1000.usb: dr_mode: 1, drd: auto mtu3 112a1000.usb: u2p_dis_msk: 0, u3p_dis_msk: 0 mtu3 112a1000.usb: usb3-drd: 0 xhci-mtk 112a0000.usb: supply vusb33 not found, using dummy regulator xhci-mtk 112a0000.usb: xHCI Host Controller xhci-mtk 112a0000.usb: new USB bus registered, assigned bus number 3 xhci-mtk 112a0000.usb: USB3 root hub has no ports xhci-mtk 112a0000.usb: hcc params 0x01400f99 hci version 0x110 quirks 0x0000000000200010 xhci-mtk 112a0000.usb: irq 288, io mem 0x112a0000 usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.16 usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb3: Product: xHCI Host Controller usb usb3: Manufacturer: Linux 6.16.4 xhci-hcd usb usb3: SerialNumber: 112a0000.usb hub 3-0:1.0: USB hub found hub 3-0:1.0: 1 port detected mtu3 112a1000.usb: xHCI platform device register success... mtu3 112b1000.usb: uwk - reg:0x400, version:106 mtu3 112b1000.usb: dr_mode: 1, drd: auto mtu3 112b1000.usb: u2p_dis_msk: 0, u3p_dis_msk: 0 mtu3 112b1000.usb: usb3-drd: 0 xhci-mtk 112b0000.usb: supply vusb33 not found, using dummy regulator xhci-mtk 112b0000.usb: xHCI Host Controller xhci-mtk 112b0000.usb: new USB bus registered, assigned bus number 4 xhci-mtk 112b0000.usb: USB3 root hub has no ports xhci-mtk 112b0000.usb: hcc params 0x01400f99 hci version 0x110 quirks 0x0000000020200010 xhci-mtk 112b0000.usb: irq 289, io mem 0x112b0000 usb usb4: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.16 usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb4: Product: xHCI Host Controller usb usb4: Manufacturer: Linux 6.16.4 xhci-hcd usb usb4: SerialNumber: 112b0000.usb hub 4-0:1.0: USB hub found hub 4-0:1.0: 1 port detected mtu3 112b1000.usb: xHCI platform device register success... thermal thermal_zone17: power_allocator: sustainable_power will be estimated thermal thermal_zone18: power_allocator: sustainable_power will be estimated mtk-msdc 11240000.mmc: Got CD GPIO usb 1-1: new high-speed USB device number 2 using xhci-mtk usb 3-1: new high-speed USB device number 2 using xhci-mtk usb 1-1: New USB device found, idVendor=05e3, idProduct=0610, bcdDevice=65.02 usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 1-1: Product: USB2.1 Hub usb 1-1: Manufacturer: GenesysLogic hub 1-1:1.0: USB hub found hub 1-1:1.0: 3 ports detected usb 4-1: new high-speed USB device number 2 using xhci-mtk usb 2-1: new SuperSpeed USB device number 2 using xhci-mtk usb 2-1: New USB device found, idVendor=05e3, idProduct=0620, bcdDevice=65.02 usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-1: Product: USB3.2 Hub usb 2-1: Manufacturer: GenesysLogic hub 2-1:1.0: USB hub found hub 2-1:1.0: 3 ports detected usb 3-1: New USB device found, idVendor=0408, idProduct=4034, bcdDevice= 0.02 usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-1: Product: ACER HD User Facing usb 3-1: Manufacturer: Quanta usb 3-1: SerialNumber: 01.00.00 usb 4-1: New USB device found, idVendor=04ca, idProduct=3802, bcdDevice= 1.00 usb 4-1: New USB device strings: Mfr=5, Product=6, SerialNumber=7 usb 4-1: Product: Wireless_Device usb 4-1: Manufacturer: MediaTek Inc. usb 4-1: SerialNumber: 000000000 panel-simple-dp-aux aux-1c500000.edp-tx: Detected BOE NE135FBM-N41 v8.1 (0x095f) xhci-mtk 11290000.usb: uwk - reg:0x400, version:104 xhci-mtk 11290000.usb: xHCI Host Controller xhci-mtk 11290000.usb: new USB bus registered, assigned bus number 5 xhci-mtk 11290000.usb: hcc params 0x01400f99 hci version 0x110 quirks 0x0000000000200010 xhci-mtk 11290000.usb: irq 291, io mem 0x11290000 xhci-mtk 11290000.usb: xHCI Host Controller xhci-mtk 11290000.usb: new USB bus registered, assigned bus number 6 xhci-mtk 11290000.usb: Host supports USB 3.2 Enhanced SuperSpeed usb usb5: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 6.16 usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb5: Product: xHCI Host Controller usb usb5: Manufacturer: Linux 6.16.4 xhci-hcd usb usb5: SerialNumber: 11290000.usb hub 5-0:1.0: USB hub found hub 5-0:1.0: 1 port detected usb usb6: We don't know the algorithms for LPM for this host, disabling LPM. usb usb6: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.16 usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb6: Product: xHCI Host Controller usb usb6: Manufacturer: Linux 6.16.4 xhci-hcd usb usb6: SerialNumber: 11290000.usb hub 6-0:1.0: USB hub found hub 6-0:1.0: 1 port detected i2c_hid_of 4-0010: supply vddl not found, using dummy regulator platform 14001000.dma-controller: Adding to iommu group 0 platform 14009000.display: Adding to iommu group 0 platform 1400c000.dma-controller: Adding to iommu group 0 platform 14f0a000.dma-controller: Adding to iommu group 0 platform 14f25000.dma-controller: Adding to iommu group 0 platform soc:jpgenc-master: Adding to iommu group 1 i2c_hid_of 4-0010: i2c_hid_get_input: IRQ triggered but there's no data platform 1c105000.dma-controller: Adding to iommu group 2 input: hid-over-i2c 04F3:4040 Touchscreen as /devices/platform/soc/11e04000.i2c/i2c-4/4-0010/0018:04F3:4040.0001/input/input2 platform 1c107000.dma-controller: Adding to iommu group 2 input: hid-over-i2c 04F3:4040 as /devices/platform/soc/11e04000.i2c/i2c-4/4-0010/0018:04F3:4040.0001/input/input3 platform 1c109000.dma-controller: Adding to iommu group 2 input: hid-over-i2c 04F3:4040 as /devices/platform/soc/11e04000.i2c/i2c-4/4-0010/0018:04F3:4040.0001/input/input4 platform 1c10b000.dma-controller: Adding to iommu group 2 input: hid-over-i2c 04F3:4040 Stylus as /devices/platform/soc/11e04000.i2c/i2c-4/4-0010/0018:04F3:4040.0001/input/input5 platform 1c114000.hdr-engine: Adding to iommu group 2 hid-generic 0018:04F3:4040.0001: input,hidraw0: I2C HID v1.00 Device [hid-over-i2c 04F3:4040] on 4-0010 mtk-iommu 14018000.iommu: bound 1c019000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 1c103000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 14013000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 14f03000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 14e05000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 15340000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 16002000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 16012000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 17201000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 1b010000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 1803e000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 1800e000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 16142000.larb (ops 0xffff800080611fb8) mtk-iommu 14018000.iommu: bound 16014000.larb (ops 0xffff800080611fb8) platform 14f08000.dma-controller: Adding to iommu group 0 platform 14f09000.dma-controller: Adding to iommu group 0 platform 14f1f000.display: Adding to iommu group 0 platform 14f23000.dma-controller: Adding to iommu group 0 platform 14f24000.dma-controller: Adding to iommu group 0 platform 18000000.video-codec: Adding to iommu group 1 platform 1a020000.video-codec: Adding to iommu group 1 platform soc:jpgdec-master: Adding to iommu group 1 platform 1c000000.ovl: Adding to iommu group 2 platform 1c002000.rdma: Adding to iommu group 2 platform 1c104000.dma-controller: Adding to iommu group 2 platform 1c106000.dma-controller: Adding to iommu group 2 platform 1c108000.dma-controller: Adding to iommu group 2 platform 1c10a000.dma-controller: Adding to iommu group 2 mtk-iommu 1c01f000.iommu: bound 1c018000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 1c102000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 14f02000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 14e04000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 15001000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 15120000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 15230000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 16001000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 16013000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 1a010000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 1802e000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 1800d000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 16141000.larb (ops 0xffff800080611fb8) mtk-iommu 1c01f000.iommu: bound 16015000.larb (ops 0xffff800080611fb8) rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=1751 rcu: (detected by 0, t=5252 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=6170 rcu: (detected by 0, t=21007 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=10589 rcu: (detected by 0, t=36762 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=15008 rcu: (detected by 0, t=52517 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=19427 rcu: (detected by 0, t=68272 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=23846 rcu: (detected by 0, t=84027 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=28265 rcu: (detected by 0, t=99782 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=32684 rcu: (detected by 0, t=115537 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=37103 rcu: (detected by 0, t=131292 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=41522 rcu: (detected by 0, t=147047 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=45941 rcu: (detected by 0, t=162802 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=50360 rcu: (detected by 0, t=178557 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=54779 rcu: (detected by 0, t=194312 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: random: crng init done rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=59198 rcu: (detected by 0, t=210067 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=63617 rcu: (detected by 0, t=225822 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=68036 rcu: (detected by 0, t=241577 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=72455 rcu: (detected by 0, t=257332 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=76874 rcu: (detected by 0, t=273087 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=81293 rcu: (detected by 0, t=288842 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=85712 rcu: (detected by 0, t=304597 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=90131 rcu: (detected by 0, t=320352 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=94550 rcu: (detected by 0, t=336107 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=98969 rcu: (detected by 0, t=351862 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=103388 rcu: (detected by 0, t=367617 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=107807 rcu: (detected by 0, t=383372 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=112226 rcu: (detected by 0, t=399127 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=116645 rcu: (detected by 0, t=414882 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=121064 rcu: (detected by 0, t=430637 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=125483 rcu: (detected by 0, t=446392 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=129902 rcu: (detected by 0, t=462147 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=134321 rcu: (detected by 0, t=477902 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=138740 rcu: (detected by 0, t=493657 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5: rcu: INFO: rcu_sched detected stalls on CPUs/tasks: rcu: 5-...0: (37 ticks this GP) idle=39b4/1/0x4000000000000000 softirq=263/265 fqs=143159 rcu: (detected by 0, t=509412 jiffies, g=-919, q=73 ncpus=8) Sending NMI from CPU 0 to CPUs 5:

1 week, 1 day

3
2
0 0

[PATCH] powerpc/powermac: Fix reference count leak in i2c probe functions

by Miaoqian Lin

The of_find_node_by_name() function returns a device tree node with its reference count incremented. The caller is responsible for calling of_node_put() to release this reference when done. Fixes: 730745a5c450 ("[PATCH] 1/5 powerpc: Rework PowerMac i2c part 1") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- arch/powerpc/platforms/powermac/low_i2c.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/platforms/powermac/low_i2c.c b/arch/powerpc/platforms/powermac/low_i2c.c index 02474e27df9b..f04dbb93bbfa 100644 --- a/arch/powerpc/platforms/powermac/low_i2c.c +++ b/arch/powerpc/platforms/powermac/low_i2c.c @@ -802,8 +802,10 @@ static void __init pmu_i2c_probe(void) for (channel = 1; channel <= 2; channel++) { sz = sizeof(struct pmac_i2c_bus) + sizeof(struct adb_request); bus = kzalloc(sz, GFP_KERNEL); - if (bus == NULL) + if (bus == NULL) { + of_node_put(busnode); return; + } bus->controller = busnode; bus->busnode = busnode; @@ -928,6 +930,7 @@ static void __init smu_i2c_probe(void) bus = kzalloc(sz, GFP_KERNEL); if (bus == NULL) { of_node_put(busnode); + of_node_put(controller); return; } -- 2.39.5 (Apple Git-154)

1 week, 1 day

1
0
0 0

[PATCH] drm/tegra: Fix reference count leak in tegra_dc_couple

by Miaoqian Lin

The driver_find_device() function returns a device with its reference count incremented. The caller is responsible for calling put_device() to release this reference when done. Fix this leak by adding the missing put_device() call. Found via static analysis. Fixes: f68ba6912bd2 ("drm/tegra: dc: Link DC1 to DC0 on Tegra20") Cc: stable(a)vger.kernel.org Signed-off-by: Miaoqian Lin <linmq006(a)gmail.com> --- drivers/gpu/drm/tegra/dc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index 59d5c1ba145a..6c84bd69b11f 100644 --- a/drivers/gpu/drm/tegra/dc.c +++ b/drivers/gpu/drm/tegra/dc.c @@ -3148,6 +3148,7 @@ static int tegra_dc_couple(struct tegra_dc *dc) dc->client.parent = &parent->client; dev_dbg(dc->dev, "coupled to %s\n", dev_name(companion)); + put_device(companion); } return 0; -- 2.39.5 (Apple Git-154)

1 week, 1 day

1
0
0 0

[PATCH 5.10] scsi: target: target_core_configfs: Add length check to avoid buffer overflow

by Andrey Troshin

From: Wang Haoran <haoranwangsec(a)gmail.com> commit 27e06650a5eafe832a90fd2604f0c5e920857fae upstream. A buffer overflow arises from the usage of snprintf to write into the buffer "buf" in target_lu_gp_members_show function located in /drivers/target/target_core_configfs.c. This buffer is allocated with size LU_GROUP_NAME_BUF (256 bytes). snprintf(...) formats multiple strings into buf with the HBA name (hba->hba_group.cg_item), a slash character, a devicename (dev-> dev_group.cg_item) and a newline character, the total formatted string length may exceed the buffer size of 256 bytes. Since snprintf() returns the total number of bytes that would have been written (the length of %s/%sn ), this value may exceed the buffer length (256 bytes) passed to memcpy(), this will ultimately cause function memcpy reporting a buffer overflow error. An additional check of the return value of snprintf() can avoid this buffer overflow. Reported-by: Wang Haoran <haoranwangsec(a)gmail.com> Reported-by: ziiiro <yuanmingbuaa(a)gmail.com> Signed-off-by: Wang Haoran <haoranwangsec(a)gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> [Andrey Troshin: patch adaptation for linux-5.10] Signed-off-by: Andrey Troshin <drtrosh(a)yandex-team.ru> --- Backport fix for CVE-2025-39998 Link: https://nvd.nist.gov/vuln/detail/CVE-2025-39998 --- drivers/target/target_core_configfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/target/target_core_configfs.c b/drivers/target/target_core_configfs.c index 4d2fbe1429b6..e6996428c07d 100644 --- a/drivers/target/target_core_configfs.c +++ b/drivers/target/target_core_configfs.c @@ -2637,7 +2637,7 @@ static ssize_t target_lu_gp_members_show(struct config_item *item, char *page) config_item_name(&dev->dev_group.cg_item)); cur_len++; /* Extra byte for NULL terminator */ - if ((cur_len + len) > PAGE_SIZE) { + if ((cur_len + len) > PAGE_SIZE || cur_len > LU_GROUP_NAME_BUF) { pr_warn("Ran out of lu_gp_show_attr" "_members buffer\n"); break; -- 2.34.1

1 week, 2 days

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror