March 2025 - Linux-stable-mirror

[PATCH] drm/dp_mst: Fix locking when skipping CSN before topology probing

by Imre Deak

The handling of the MST Connection Status Notify message is skipped if the probing of the topology is still pending. Acquiring the drm_dp_mst_topology_mgr::probe_lock for this in drm_dp_mst_handle_up_req() is problematic: the task/work this function is called from is also responsible for handling MST down-request replies (in drm_dp_mst_handle_down_rep()). Thus drm_dp_mst_link_probe_work() - holding already probe_lock - could be blocked waiting for an MST down-request reply while drm_dp_mst_handle_up_req() is waiting for probe_lock while processing a CSN message. This leads to the probe work's down-request message timing out. A scenario similar to the above leading to a down-request timeout is handling a CSN message in drm_dp_mst_handle_conn_stat(), holding the probe_lock and sending down-request messages while a second CSN message sent by the sink subsequently is handled by drm_dp_mst_handle_up_req(). Fix the above by moving the logic to skip the CSN handling to drm_dp_mst_process_up_req(). This function is called from a work (separate from the task/work handling new up/down messages), already holding probe_lock. This solves the above timeout issue, since handling of down-request replies won't be blocked by probe_lock. Fixes: ddf983488c3e ("drm/dp_mst: Skip CSN if topology probing is not done yet") Cc: Wayne Lin <Wayne.Lin(a)amd.com> Cc: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org # v6.6+ Signed-off-by: Imre Deak <imre.deak(a)intel.com> --- drivers/gpu/drm/display/drm_dp_mst_topology.c | 40 +++++++++++-------- 1 file changed, 24 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c b/drivers/gpu/drm/display/drm_dp_mst_topology.c index 8b68bb3fbffb0..3a1f1ffc7b552 100644 --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c @@ -4036,6 +4036,22 @@ static int drm_dp_mst_handle_down_rep(struct drm_dp_mst_topology_mgr *mgr) return 0; } +static bool primary_mstb_probing_is_done(struct drm_dp_mst_topology_mgr *mgr) +{ + bool probing_done = false; + + mutex_lock(&mgr->lock); + + if (mgr->mst_primary && drm_dp_mst_topology_try_get_mstb(mgr->mst_primary)) { + probing_done = mgr->mst_primary->link_address_sent; + drm_dp_mst_topology_put_mstb(mgr->mst_primary); + } + + mutex_unlock(&mgr->lock); + + return probing_done; +} + static inline bool drm_dp_mst_process_up_req(struct drm_dp_mst_topology_mgr *mgr, struct drm_dp_pending_up_req *up_req) @@ -4066,8 +4082,12 @@ drm_dp_mst_process_up_req(struct drm_dp_mst_topology_mgr *mgr, /* TODO: Add missing handler for DP_RESOURCE_STATUS_NOTIFY events */ if (msg->req_type == DP_CONNECTION_STATUS_NOTIFY) { - dowork = drm_dp_mst_handle_conn_stat(mstb, &msg->u.conn_stat); - hotplug = true; + if (!primary_mstb_probing_is_done(mgr)) { + drm_dbg_kms(mgr->dev, "Got CSN before finish topology probing. Skip it.\n"); + } else { + dowork = drm_dp_mst_handle_conn_stat(mstb, &msg->u.conn_stat); + hotplug = true; + } } drm_dp_mst_topology_put_mstb(mstb); @@ -4149,10 +4169,11 @@ static int drm_dp_mst_handle_up_req(struct drm_dp_mst_topology_mgr *mgr) drm_dp_send_up_ack_reply(mgr, mst_primary, up_req->msg.req_type, false); + drm_dp_mst_topology_put_mstb(mst_primary); + if (up_req->msg.req_type == DP_CONNECTION_STATUS_NOTIFY) { const struct drm_dp_connection_status_notify *conn_stat = &up_req->msg.u.conn_stat; - bool handle_csn; drm_dbg_kms(mgr->dev, "Got CSN: pn: %d ldps:%d ddps: %d mcs: %d ip: %d pdt: %d\n", conn_stat->port_number, @@ -4161,16 +4182,6 @@ static int drm_dp_mst_handle_up_req(struct drm_dp_mst_topology_mgr *mgr) conn_stat->message_capability_status, conn_stat->input_port, conn_stat->peer_device_type); - - mutex_lock(&mgr->probe_lock); - handle_csn = mst_primary->link_address_sent; - mutex_unlock(&mgr->probe_lock); - - if (!handle_csn) { - drm_dbg_kms(mgr->dev, "Got CSN before finish topology probing. Skip it."); - kfree(up_req); - goto out_put_primary; - } } else if (up_req->msg.req_type == DP_RESOURCE_STATUS_NOTIFY) { const struct drm_dp_resource_status_notify *res_stat = &up_req->msg.u.resource_stat; @@ -4185,9 +4196,6 @@ static int drm_dp_mst_handle_up_req(struct drm_dp_mst_topology_mgr *mgr) list_add_tail(&up_req->next, &mgr->up_req_list); mutex_unlock(&mgr->up_req_lock); queue_work(system_long_wq, &mgr->up_req_work); - -out_put_primary: - drm_dp_mst_topology_put_mstb(mst_primary); out_clear_reply: reset_msg_rx_state(&mgr->up_req_recv); return ret; -- 2.44.2

8 months

3
5
0 0

[5.4/5.10/5.15/6.1/6.6] spi-mxs: Fix chipselect glitch

by Stefan Wahren

Dear stable team, I noticed that ceeeb99cd821 ("dmaengine: mxs: rename custom flag") got backported, but the additional fix 269e31aecdd0 ("spi-mxs: Fix chipselect glitch") hasn't. I think was caused by the lack of Cc to stable. Without the latter patch the SPI is causing glitches on MXS platform. Please backport it from 5.4 to 6.6. Thanks Stefan

8 months

2
2
0 0

[PATCH 1/2] regulator: dummy: force synchronous probing

by Christian Eggers

Sometimes I get a NULL pointer dereference at boot time in kobject_get() with the following call stack: anatop_regulator_probe() devm_regulator_register() regulator_register() regulator_resolve_supply() kobject_get() By placing some extra BUG_ON() statements I could verify that this is raised because probing of the 'dummy' regulator driver is not completed ('dummy_regulator_rdev' is still NULL). In the JTAG debugger I can see that dummy_regulator_probe() and anatop_regulator_probe() can be run by different kernel threads (kworker/u4:*). I haven't further investigated whether this can be changed or if there are other possibilities to force synchronization between these two probe routines. On the other hand I don't expect much boot time penalty by probing the 'dummy' regulator synchronously. Cc: stable(a)vger.kernel.org Fixes: 259b93b21a9f ("regulator: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in 4.14") Signed-off-by: Christian Eggers <ceggers(a)arri.de> --- drivers/regulator/dummy.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/regulator/dummy.c b/drivers/regulator/dummy.c index 5b9b9e4e762d..9f59889129ab 100644 --- a/drivers/regulator/dummy.c +++ b/drivers/regulator/dummy.c @@ -60,7 +60,7 @@ static struct platform_driver dummy_regulator_driver = { .probe = dummy_regulator_probe, .driver = { .name = "reg-dummy", - .probe_type = PROBE_PREFER_ASYNCHRONOUS, + .probe_type = PROBE_FORCE_SYNCHRONOUS, }, }; -- 2.43.0

8 months

3
4
0 0

[PATCH 2/3] usb: chipidea: ci_hdrc_imx: disable regulator on error path in probe

by Fedor Pchelkin

Upon encountering errors during the HSIC pinctrl handling section the regulator should be disabled. After the above-stated changes it is possible to jump onto "disable_hsic_regulator" label without having added the CPU latency QoS request previously. This would result in cpu_latency_qos_remove_request() yielding a WARNING. So rearrange the error handling path to follow the reverse order of different probing phases. Found by Linux Verification Center (linuxtesting.org). Fixes: 4d6141288c33 ("usb: chipidea: imx: pinctrl for HSIC is optional") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> --- drivers/usb/chipidea/ci_hdrc_imx.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c index 619779eef333..3f11ae071c7f 100644 --- a/drivers/usb/chipidea/ci_hdrc_imx.c +++ b/drivers/usb/chipidea/ci_hdrc_imx.c @@ -407,13 +407,13 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev) "pinctrl_hsic_idle lookup failed, err=%ld\n", PTR_ERR(pinctrl_hsic_idle)); ret = PTR_ERR(pinctrl_hsic_idle); - goto err_put; + goto disable_hsic_regulator; } ret = pinctrl_select_state(data->pinctrl, pinctrl_hsic_idle); if (ret) { dev_err(dev, "hsic_idle select failed, err=%d\n", ret); - goto err_put; + goto disable_hsic_regulator; } data->pinctrl_hsic_active = pinctrl_lookup_state(data->pinctrl, @@ -423,7 +423,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev) "pinctrl_hsic_active lookup failed, err=%ld\n", PTR_ERR(data->pinctrl_hsic_active)); ret = PTR_ERR(data->pinctrl_hsic_active); - goto err_put; + goto disable_hsic_regulator; } } @@ -432,11 +432,11 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev) ret = imx_get_clks(dev); if (ret) - goto disable_hsic_regulator; + goto qos_remove_request; ret = imx_prepare_enable_clks(dev); if (ret) - goto disable_hsic_regulator; + goto qos_remove_request; ret = clk_prepare_enable(data->clk_wakeup); if (ret) @@ -526,12 +526,13 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev) clk_disable_unprepare(data->clk_wakeup); err_wakeup_clk: imx_disable_unprepare_clks(dev); +qos_remove_request: + if (pdata.flags & CI_HDRC_PMQOS) + cpu_latency_qos_remove_request(&data->pm_qos_req); disable_hsic_regulator: if (data->hsic_pad_regulator) /* don't overwrite original ret (cf. EPROBE_DEFER) */ regulator_disable(data->hsic_pad_regulator); - if (pdata.flags & CI_HDRC_PMQOS) - cpu_latency_qos_remove_request(&data->pm_qos_req); data->ci_pdev = NULL; err_put: if (data->usbmisc_data) -- 2.48.1

8 months

2
2
0 0

[PATCH 6.1.y] KVM: selftests: Fix build error due to assert in dirty_log_test

by Andrey Kalachev

Hi all. Please apply that forgotten patch to fix v6.1 KVM selftests broken build. Origin of the patch can be founded here [1] Regards, AK [1] https://lore.kernel.org/stable/20240403164230.1722018-1-rananta@google.com/ -- 2.30.2

8 months

1
1
0 0

Re: Patch "drm/i915: Plumb 'dsb' all way to the plane hooks" has been added to the 6.12-stable tree

by Ville Syrjälä

On Sun, Mar 09, 2025 at 03:45:57PM -0400, Sasha Levin wrote: > This is a note to let you know that I've just added the patch titled > > drm/i915: Plumb 'dsb' all way to the plane hooks > > to the 6.12-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > drm-i915-plumb-dsb-all-way-to-the-plane-hooks.patch > and it can be found in the queue-6.12 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > > > commit f03e7cca22f4bb50cae98840f91fcf1e6d780a54 > Author: Ville Syrjälä <ville.syrjala(a)linux.intel.com> > Date: Mon Sep 30 20:04:13 2024 +0300 > > drm/i915: Plumb 'dsb' all way to the plane hooks > > [ Upstream commit 01389846f7d61d262cc92d42ad4d1a25730e3eff ] It would help if you actually mentioned *why* you need to backport this? -- Ville Syrjälä Intel

8 months

2
2
0 0

[REGRESSION] stable-rc/linux-5.4.y: (build) +arch/x86/events/amd/../perf_event.h:855:21: error: invalid output...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.4.y: --- +arch/x86/events/amd/../perf_event.h:855:21: error: invalid output size for constraint '=q' in arch/x86/events/amd/core.o (arch/x86/events/amd/core.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/issue/maestro:d36536187d181e0823b2aa631ebf9936dd657c… - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 888d41479bea1f83b835311f71a91f5e08f6c4d7 Log excerpt: ===================================================== In file included from arch/x86/events/amd/core.c:12: +arch/x86/events/amd/../perf_event.h:855:21: error: invalid output size for constraint '=q' ./include/linux/percpu-defs.h:446:2: note: expanded from macro '__this_cpu_read' 446 | raw_cpu_read(pcp); \ | ^ ./include/linux/percpu-defs.h:420:28:.. note: expanded from macro 'raw_cpu_read' 420 | #define raw_cpu_read(pcp) __pcpu_size_call_return(raw_cpu_read_, pcp) | ^ ./include/linux/percpu-defs.h:323:23: note: expanded from macro '__pcpu_size_call_return' 323 | case 4: pscr_ret__ = stem##4(variable); break; \ | ^ <scratch space>:85:1: note: expanded from here 85 | raw_cpu_read_4 | ^ ./arch/x86/include/asm/percpu.h:396:30: note: expanded from macro 'raw_cpu_read_4' 396 | #define raw_cpu_read_4(pcp) percpu_from_op(, "mov", pcp) | ^ ./arch/x86/include/asm/percpu.h:189:15: note: expanded from macro 'percpu_from_op' 189 | : "=q" (pfo_ret__) \ | ^ ....+. HDRTEST usr/include/sound/sof/tokens.h . AR init/built-in.a ..........6 errors generated. ....+..... ===================================================== # Builds where the incident occurred: ## i386_defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (i386): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:67ceff2318018371957eaf29 #kernelci issue maestro:d36536187d181e0823b2aa631ebf9936dd657c55 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

8 months

1
0
0 0

[REGRESSION] stable-rc/linux-6.6.y: (build) ‘RISCV_ISA_EXT_XLINUXENVCFG’ undeclared (first use in this functio...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-6.6.y: --- ‘RISCV_ISA_EXT_XLINUXENVCFG’ undeclared (first use in this function); did you mean ‘RISCV_ISA_EXT_ZIFENCEI’? in arch/riscv/kernel/suspend.o (arch/riscv/kernel/suspend.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/issue/maestro:f277022d07efdd2a5858eb44b3c3dab79cca84… - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: b49d45c66a5e8cc1c82591049bfc0d04daa1e77c Log excerpt: ===================================================== arch/riscv/kernel/suspend.c:14:66: error: ‘RISCV_ISA_EXT_XLINUXENVCFG’ undeclared (first use in this function); did you mean ‘RISCV_ISA_EXT_ZIFENCEI’? 14 | if (riscv_cpu_has_extension_unlikely(smp_processor_id(), RISCV_ISA_EXT_XLINUXENVCFG)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ | RISCV_ISA_EXT_ZIFENCEI arch/riscv/kernel/suspend.c:14:66: note: each undeclared identifier is reported only once for each function it appears in CC fs/proc/cpuinfo.o arch/riscv/kernel/suspend.c: In function ‘suspend_restore_csrs’: arch/riscv/kernel/suspend.c:37:66: error: ‘RISCV_ISA_EXT_XLINUXENVCFG’ undeclared (first use in this function); did you mean ‘RISCV_ISA_EXT_ZIFENCEI’? 37 | if (riscv_cpu_has_extension_unlikely(smp_processor_id(), RISCV_ISA_EXT_XLINUXENVCFG)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~ | RISCV_ISA_EXT_ZIFENCEI ===================================================== # Builds where the incident occurred: ## defconfig on (riscv): - compiler: gcc-12 - dashboard: https://d.kernelci.org/build/maestro:67cf00ee18018371957ec83e #kernelci issue maestro:f277022d07efdd2a5858eb44b3c3dab79cca847e 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

8 months

1
0
0 0

[PATCH] mm/huge_memory: drop beyond-EOF folios with the right number of refs.

by Zi Yan

When an after-split folio is large and needs to be dropped due to EOF, folio_put_refs(folio, folio_nr_pages(folio)) should be used to drop all page cache refs. Otherwise, the folio will not be freed, causing memory leak. This leak would happen on a filesystem with blocksize > page_size and a truncate is performed, where the blocksize makes folios split to >0 order ones, causing truncated folios not being freed. Fixes: c010d47f107f ("mm: thp: split huge page to any lower order pages") Reported-by: Hugh Dickins <hughd(a)google.com> Closes: https://lore.kernel.org/all/fcbadb7f-dd3e-21df-f9a7-2853b53183c4@google.com/ Cc: stable(a)vger.kernel.org Signed-off-by: Zi Yan <ziy(a)nvidia.com> --- mm/huge_memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 3d3ebdc002d5..373781b21e5c 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -3304,7 +3304,7 @@ static void __split_huge_page(struct page *page, struct list_head *list, folio_account_cleaned(tail, inode_to_wb(folio->mapping->host)); __filemap_remove_folio(tail, NULL); - folio_put(tail); + folio_put_refs(tail, folio_nr_pages(tail)); } else if (!folio_test_anon(folio)) { __xa_store(&folio->mapping->i_pages, tail->index, tail, 0); -- 2.47.2

8 months

1
0
0 0

net: cadence: macb: Enable software IRQ coalescing by default

by Daniel J Blueman

The macb ethernet driver (Raspberry Pi 5) delivers interrupts only to the first core, quickly saturating it at higher packet rates. Introducing software interrupt coalescing dramatically alleviates this limitation; the oneliner fix is upstream at d57f7b45945ac0517ff8ea50655f00db6e8d637c. Please backport this fix to 6.6 -stable to bring this benefit to more Raspberry Pis; it applies cleanly on this branch. Many thanks, Daniel -- Daniel J Blueman

8 months

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror March 2025