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

[PATCH v2] drm/amdgpu: don't attach the tlb fence for SI

by Hans de Goede

From: Alex Deucher <alexander.deucher(a)amd.com> commit eb296c09805ee37dd4ea520a7fb3ec157c31090f upstream. SI hardware doesn't support pasids, user mode queues, or KIQ/MES so there is no need for this. Doing so results in a segfault as these callbacks are non-existent for SI. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4744 Fixes: b4a7f4e7ad2b ("drm/amdgpu: attach tlb fence to the PTs update") Reviewed-by: Timur Kristóf <timur.kristof(a)gmail.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> (cherry picked from commit 820b3d376e8a102c6aeab737ec6edebbbb710e04) Signed-off-by: Hans de Goede <johannes.goede(a)oss.qualcomm.com> --- Changes in v2 stable submission: - Correct the Fixes: tag hash which is wrong in the original upstream commit eb296c09805e ("drm/amdgpu: don't attach the tlb fence for SI") --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c index 676e24fb8864..cdcafde3c71a 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c @@ -1066,7 +1066,9 @@ amdgpu_vm_tlb_flush(struct amdgpu_vm_update_params *params, } /* Prepare a TLB flush fence to be attached to PTs */ - if (!params->unlocked) { + if (!params->unlocked && + /* SI doesn't support pasid or KIQ/MES */ + params->adev->family > AMDGPU_FAMILY_SI) { amdgpu_vm_tlb_fence_create(params->adev, vm, fence); /* Makes sure no PD/PT is freed before the flush */ -- 2.52.0

4 days, 21 hours

1
0
0 0

[PATCH 2/2] block/blk-mq: convert blk_mq_cpuhp_lock to raw_spinlock for RT

by Ionut Nechita (WindRiver)

From: Ionut Nechita <ionut.nechita(a)windriver.com> Commit 58bf93580fec ("blk-mq: move cpuhp callback registering out of q->sysfs_lock") introduced a global mutex blk_mq_cpuhp_lock to avoid lockdep warnings between sysfs_lock and CPU hotplug lock. On RT kernels (CONFIG_PREEMPT_RT), regular mutexes are converted to rt_mutex (sleeping locks). When block layer operations need to acquire blk_mq_cpuhp_lock, IRQ threads processing I/O completions may sleep, causing additional contention on top of the queue_lock issue from commit 679b1874eba7 ("block: fix ordering between checking QUEUE_FLAG_QUIESCED request adding"). Test case (MegaRAID 12GSAS with 8 MSI-X vectors on RT kernel): - v6.6.68-rt with queue_lock fix: 640 MB/s (queue_lock fixed) - v6.6.69-rt: still exhibits contention due to cpuhp_lock mutex The functions protected by blk_mq_cpuhp_lock only perform fast, non-sleeping operations: - hlist_unhashed() checks - cpuhp_state_add_instance_nocalls() - just hlist manipulation - cpuhp_state_remove_instance_nocalls() - just hlist manipulation - INIT_HLIST_NODE() initialization The _nocalls variants do not invoke state callbacks and only manipulate data structures, making them safe to call under raw_spinlock. Convert blk_mq_cpuhp_lock from mutex to raw_spinlock to prevent it from becoming a sleeping lock in RT kernel. This eliminates the contention bottleneck while maintaining the lockdep fix's original intent. Fixes: 58bf93580fec ("blk-mq: move cpuhp callback registering out of q->sysfs_lock") Cc: stable(a)vger.kernel.org Signed-off-by: Ionut Nechita <ionut.nechita(a)windriver.com> --- block/blk-mq.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/block/blk-mq.c b/block/blk-mq.c index 5fb8da4958d0..3982e24b1081 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -43,7 +43,7 @@ static DEFINE_PER_CPU(struct llist_head, blk_cpu_done); static DEFINE_PER_CPU(call_single_data_t, blk_cpu_csd); -static DEFINE_MUTEX(blk_mq_cpuhp_lock); +static DEFINE_RAW_SPINLOCK(blk_mq_cpuhp_lock); static void blk_mq_insert_request(struct request *rq, blk_insert_t flags); static void blk_mq_request_bypass_insert(struct request *rq, @@ -3641,9 +3641,9 @@ static void __blk_mq_remove_cpuhp(struct blk_mq_hw_ctx *hctx) static void blk_mq_remove_cpuhp(struct blk_mq_hw_ctx *hctx) { - mutex_lock(&blk_mq_cpuhp_lock); + raw_spin_lock(&blk_mq_cpuhp_lock); __blk_mq_remove_cpuhp(hctx); - mutex_unlock(&blk_mq_cpuhp_lock); + raw_spin_unlock(&blk_mq_cpuhp_lock); } static void __blk_mq_add_cpuhp(struct blk_mq_hw_ctx *hctx) @@ -3683,9 +3683,9 @@ static void blk_mq_remove_hw_queues_cpuhp(struct request_queue *q) list_splice_init(&q->unused_hctx_list, &hctx_list); spin_unlock(&q->unused_hctx_lock); - mutex_lock(&blk_mq_cpuhp_lock); + raw_spin_lock(&blk_mq_cpuhp_lock); __blk_mq_remove_cpuhp_list(&hctx_list); - mutex_unlock(&blk_mq_cpuhp_lock); + raw_spin_unlock(&blk_mq_cpuhp_lock); spin_lock(&q->unused_hctx_lock); list_splice(&hctx_list, &q->unused_hctx_list); @@ -3702,10 +3702,10 @@ static void blk_mq_add_hw_queues_cpuhp(struct request_queue *q) struct blk_mq_hw_ctx *hctx; unsigned long i; - mutex_lock(&blk_mq_cpuhp_lock); + raw_spin_lock(&blk_mq_cpuhp_lock); queue_for_each_hw_ctx(q, hctx, i) __blk_mq_add_cpuhp(hctx); - mutex_unlock(&blk_mq_cpuhp_lock); + raw_spin_unlock(&blk_mq_cpuhp_lock); } /* -- 2.52.0

5 days

1
0
0 0

[PATCH 1/2] block/blk-mq: fix RT kernel regression with queue_lock in hot path

by Ionut Nechita (WindRiver)

From: Ionut Nechita <ionut.nechita(a)windriver.com> Commit 679b1874eba7 ("block: fix ordering between checking QUEUE_FLAG_QUIESCED request adding") introduced queue_lock acquisition in blk_mq_run_hw_queue() to synchronize QUEUE_FLAG_QUIESCED checks. On RT kernels (CONFIG_PREEMPT_RT), regular spinlocks are converted to rt_mutex (sleeping locks). When multiple MSI-X IRQ threads process I/O completions concurrently, they contend on queue_lock in the hot path, causing all IRQ threads to enter D (uninterruptible sleep) state. This serializes interrupt processing completely. Test case (MegaRAID 12GSAS with 8 MSI-X vectors on RT kernel): - Good (v6.6.52-rt): 640 MB/s sequential read - Bad (v6.6.64-rt): 153 MB/s sequential read (-76% regression) - 6-8 out of 8 MSI-X IRQ threads stuck in D-state waiting on queue_lock The original commit message mentioned memory barriers as an alternative approach. Use full memory barriers (smp_mb) instead of queue_lock to provide the same ordering guarantees without sleeping in RT kernel. Memory barriers ensure proper synchronization: - CPU0 either sees QUEUE_FLAG_QUIESCED cleared, OR - CPU1 sees dispatch list/sw queue bitmap updates This maintains correctness while avoiding lock contention that causes RT kernel IRQ threads to sleep in the I/O completion path. Fixes: 679b1874eba7 ("block: fix ordering between checking QUEUE_FLAG_QUIESCED request adding") Cc: stable(a)vger.kernel.org Signed-off-by: Ionut Nechita <ionut.nechita(a)windriver.com> --- block/blk-mq.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) diff --git a/block/blk-mq.c b/block/blk-mq.c index 5da948b07058..5fb8da4958d0 100644 --- a/block/blk-mq.c +++ b/block/blk-mq.c @@ -2292,22 +2292,19 @@ void blk_mq_run_hw_queue(struct blk_mq_hw_ctx *hctx, bool async) might_sleep_if(!async && hctx->flags & BLK_MQ_F_BLOCKING); + /* + * First lockless check to avoid unnecessary overhead. + * Memory barrier below synchronizes with blk_mq_unquiesce_queue(). + */ need_run = blk_mq_hw_queue_need_run(hctx); if (!need_run) { - unsigned long flags; - - /* - * Synchronize with blk_mq_unquiesce_queue(), because we check - * if hw queue is quiesced locklessly above, we need the use - * ->queue_lock to make sure we see the up-to-date status to - * not miss rerunning the hw queue. - */ - spin_lock_irqsave(&hctx->queue->queue_lock, flags); + /* Synchronize with blk_mq_unquiesce_queue() */ + smp_mb(); need_run = blk_mq_hw_queue_need_run(hctx); - spin_unlock_irqrestore(&hctx->queue->queue_lock, flags); - if (!need_run) return; + /* Ensure dispatch list/sw queue updates visible before execution */ + smp_mb(); } if (async || !cpumask_test_cpu(raw_smp_processor_id(), hctx->cpumask)) { -- 2.52.0

5 days

1
0
0 0

[PATCH 6.17.y] net: openvswitch: fix middle attribute validation in push_nsh() action

by Adrian Yip

From: Ilya Maximets <i.maximets(a)ovn.org> [ Upstream commit 5ace7ef87f059d68b5f50837ef3e8a1a4870c36e ] The push_nsh() action structure looks like this: OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...)) The outermost OVS_ACTION_ATTR_PUSH_NSH attribute is OK'ed by the nla_for_each_nested() inside __ovs_nla_copy_actions(). The innermost OVS_NSH_KEY_ATTR_BASE/MD1/MD2 are OK'ed by the nla_for_each_nested() inside nsh_key_put_from_nlattr(). But nothing checks if the attribute in the middle is OK. We don't even check that this attribute is the OVS_KEY_ATTR_NSH. We just do a double unwrap with a pair of nla_data() calls - first time directly while calling validate_push_nsh() and the second time as part of the nla_for_each_nested() macro, which isn't safe, potentially causing invalid memory access if the size of this attribute is incorrect. The failure may not be noticed during validation due to larger netlink buffer, but cause trouble later during action execution where the buffer is allocated exactly to the size: BUG: KASAN: slab-out-of-bounds in nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] Read of size 184 at addr ffff88816459a634 by task a.out/22624 CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary) Call Trace: <TASK> dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x2c/0x390 kasan_report+0xdd/0x110 kasan_check_range+0x35/0x1b0 __asan_memcpy+0x20/0x60 nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] push_nsh+0x82/0x120 [openvswitch] do_execute_actions+0x1405/0x2840 [openvswitch] ovs_execute_actions+0xd5/0x3b0 [openvswitch] ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch] genl_family_rcv_msg_doit+0x1d6/0x2b0 genl_family_rcv_msg+0x336/0x580 genl_rcv_msg+0x9f/0x130 netlink_rcv_skb+0x11f/0x370 genl_rcv+0x24/0x40 netlink_unicast+0x73e/0xaa0 netlink_sendmsg+0x744/0xbf0 __sys_sendto+0x3d6/0x450 do_syscall_64+0x79/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> Let's add some checks that the attribute is properly sized and it's the only one attribute inside the action. Technically, there is no real reason for OVS_KEY_ATTR_NSH to be there, as we know that we're pushing an NSH header already, it just creates extra nesting, but that's how uAPI works today. So, keeping as it is. Fixes: b2d0f5d5dc53 ("openvswitch: enable NSH support") Reported-by: Junvy Yang <zhuque(a)tencent.com> Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Reviewed-by: Aaron Conole <aconole(a)redhat.com> Link: https://patch.msgid.link/20251204105334.900379-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> (cherry picked from commit 5ace7ef87f059d68b5f50837ef3e8a1a4870c36e) Signed-off-by: Adrian Yip <adrian.ytw(a)gmail.com> --- net/openvswitch/flow_netlink.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c index 1cb4f97335d8..2d536901309e 100644 --- a/net/openvswitch/flow_netlink.c +++ b/net/openvswitch/flow_netlink.c @@ -2802,13 +2802,20 @@ static int validate_and_copy_set_tun(const struct nlattr *attr, return err; } -static bool validate_push_nsh(const struct nlattr *attr, bool log) +static bool validate_push_nsh(const struct nlattr *a, bool log) { + struct nlattr *nsh_key = nla_data(a); struct sw_flow_match match; struct sw_flow_key key; + /* There must be one and only one NSH header. */ + if (!nla_ok(nsh_key, nla_len(a)) || + nla_total_size(nla_len(nsh_key)) != nla_len(a) || + nla_type(nsh_key) != OVS_KEY_ATTR_NSH) + return false; + ovs_match_init(&match, &key, true, NULL); - return !nsh_key_put_from_nlattr(attr, &match, false, true, log); + return !nsh_key_put_from_nlattr(nsh_key, &match, false, true, log); } /* Return false if there are any non-masked bits set. @@ -3389,7 +3396,7 @@ static int __ovs_nla_copy_actions(struct net *net, const struct nlattr *attr, return -EINVAL; } mac_proto = MAC_PROTO_NONE; - if (!validate_push_nsh(nla_data(a), log)) + if (!validate_push_nsh(a, log)) return -EINVAL; break; -- 2.52.0

5 days, 1 hour

1
0
0 0

[PATCH 6.12.y] net: openvswitch: fix middle attribute validation in push_nsh() action

by Adrian Yip

From: Ilya Maximets <i.maximets(a)ovn.org> [ Upstream commit 5ace7ef87f059d68b5f50837ef3e8a1a4870c36e ] The push_nsh() action structure looks like this: OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...)) The outermost OVS_ACTION_ATTR_PUSH_NSH attribute is OK'ed by the nla_for_each_nested() inside __ovs_nla_copy_actions(). The innermost OVS_NSH_KEY_ATTR_BASE/MD1/MD2 are OK'ed by the nla_for_each_nested() inside nsh_key_put_from_nlattr(). But nothing checks if the attribute in the middle is OK. We don't even check that this attribute is the OVS_KEY_ATTR_NSH. We just do a double unwrap with a pair of nla_data() calls - first time directly while calling validate_push_nsh() and the second time as part of the nla_for_each_nested() macro, which isn't safe, potentially causing invalid memory access if the size of this attribute is incorrect. The failure may not be noticed during validation due to larger netlink buffer, but cause trouble later during action execution where the buffer is allocated exactly to the size: BUG: KASAN: slab-out-of-bounds in nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] Read of size 184 at addr ffff88816459a634 by task a.out/22624 CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary) Call Trace: <TASK> dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x2c/0x390 kasan_report+0xdd/0x110 kasan_check_range+0x35/0x1b0 __asan_memcpy+0x20/0x60 nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] push_nsh+0x82/0x120 [openvswitch] do_execute_actions+0x1405/0x2840 [openvswitch] ovs_execute_actions+0xd5/0x3b0 [openvswitch] ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch] genl_family_rcv_msg_doit+0x1d6/0x2b0 genl_family_rcv_msg+0x336/0x580 genl_rcv_msg+0x9f/0x130 netlink_rcv_skb+0x11f/0x370 genl_rcv+0x24/0x40 netlink_unicast+0x73e/0xaa0 netlink_sendmsg+0x744/0xbf0 __sys_sendto+0x3d6/0x450 do_syscall_64+0x79/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e </TASK> Let's add some checks that the attribute is properly sized and it's the only one attribute inside the action. Technically, there is no real reason for OVS_KEY_ATTR_NSH to be there, as we know that we're pushing an NSH header already, it just creates extra nesting, but that's how uAPI works today. So, keeping as it is. Fixes: b2d0f5d5dc53 ("openvswitch: enable NSH support") Reported-by: Junvy Yang <zhuque(a)tencent.com> Signed-off-by: Ilya Maximets <i.maximets(a)ovn.org> Acked-by: Eelco Chaudron <echaudro(a)redhat.com> Reviewed-by: Aaron Conole <aconole(a)redhat.com> Link: https://patch.msgid.link/20251204105334.900379-1-i.maximets@ovn.org Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> (cherry picked from commit 5ace7ef87f059d68b5f50837ef3e8a1a4870c36e) Signed-off-by: Adrian Yip <adrian.ytw(a)gmail.com> --- net/openvswitch/flow_netlink.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/net/openvswitch/flow_netlink.c b/net/openvswitch/flow_netlink.c index e3359e15aa2e..7d5490ea23e1 100644 --- a/net/openvswitch/flow_netlink.c +++ b/net/openvswitch/flow_netlink.c @@ -2802,13 +2802,20 @@ static int validate_and_copy_set_tun(const struct nlattr *attr, return err; } -static bool validate_push_nsh(const struct nlattr *attr, bool log) +static bool validate_push_nsh(const struct nlattr *a, bool log) { + struct nlattr *nsh_key = nla_data(a); struct sw_flow_match match; struct sw_flow_key key; + /* There must be one and only one NSH header. */ + if (!nla_ok(nsh_key, nla_len(a)) || + nla_total_size(nla_len(nsh_key)) != nla_len(a) || + nla_type(nsh_key) != OVS_KEY_ATTR_NSH) + return false; + ovs_match_init(&match, &key, true, NULL); - return !nsh_key_put_from_nlattr(attr, &match, false, true, log); + return !nsh_key_put_from_nlattr(nsh_key, &match, false, true, log); } /* Return false if there are any non-masked bits set. @@ -3388,7 +3395,7 @@ static int __ovs_nla_copy_actions(struct net *net, const struct nlattr *attr, return -EINVAL; } mac_proto = MAC_PROTO_NONE; - if (!validate_push_nsh(nla_data(a), log)) + if (!validate_push_nsh(a, log)) return -EINVAL; break; -- 2.52.0

5 days, 2 hours

1
0
0 0

[PATCH] Revert "clk: qcom: cpu-8996: simplify the cpu_clk_notifier_cb"

by Christopher Obbard

This reverts commit b3b274bc9d3d7307308aeaf75f70731765ac999a. On the DragonBoard 820c (which uses APQ8096/MSM8996) this change causes the CPUs to downclock to roughly half speed under sustained load. The regression is visible both during boot and when running CPU stress workloads such as stress-ng: the CPUs initially ramp up to the expected frequency, then drop to a lower OPP even though the system is clearly CPU-bound. Bisecting points to this commit and reverting it restores the expected behaviour on the DragonBoard 820c - the CPUs track the cpufreq policy and run at full performance under load. The exact interaction with the ACD is not yet fully understood and we would like to keep ACD in use to avoid possible SoC reliability issues. Until we have a better fix that preserves ACD while avoiding this performance regression, revert the bisected patch to restore the previous behaviour. Fixes: b3b274bc9d3d ("clk: qcom: cpu-8996: simplify the cpu_clk_notifier_cb") Cc: stable(a)vger.kernel.org # v6.3+ Link: https://lore.kernel.org/linux-arm-msm/20230113120544.59320-8-dmitry.baryshk… Cc: Dmitry Baryshkov <dmitry.baryshkov(a)oss.qualcomm.com> Signed-off-by: Christopher Obbard <christopher.obbard(a)linaro.org> --- Hi all, This series contains a single revert for a regression affecting the APQ8096/MSM8996 (DragonBoard 820c). The commit being reverted, b3b274bc9d3d ("clk: qcom: cpu-8996: simplify the cpu_clk_notifier_cb"), introduces a significant performance issue where the CPUs downclock to ~50% of their expected frequency under sustained load. The problem is reproducible both at boot and when running CPU-bound workloads such as stress-ng. Bisecting the issue pointed directly to this commit and reverting it restores correct cpufreq behaviour. The root cause appears to be related to the interaction between the simplified notifier callback and ACD (Adaptive Clock Distribution). Since we would prefer to keep ACD enabled for SoC reliability reasons, a revert is the safest option until a proper fix is identified. Full details are included in the commit message. Feedback & suggestions welcome. Cheers! Christopher Obbard --- drivers/clk/qcom/clk-cpu-8996.c | 30 +++++++++++------------------- 1 file changed, 11 insertions(+), 19 deletions(-) diff --git a/drivers/clk/qcom/clk-cpu-8996.c b/drivers/clk/qcom/clk-cpu-8996.c index 21d13c0841ed..028476931747 100644 --- a/drivers/clk/qcom/clk-cpu-8996.c +++ b/drivers/clk/qcom/clk-cpu-8996.c @@ -547,35 +547,27 @@ static int cpu_clk_notifier_cb(struct notifier_block *nb, unsigned long event, { struct clk_cpu_8996_pmux *cpuclk = to_clk_cpu_8996_pmux_nb(nb); struct clk_notifier_data *cnd = data; + int ret; switch (event) { case PRE_RATE_CHANGE: + ret = clk_cpu_8996_pmux_set_parent(&cpuclk->clkr.hw, ALT_INDEX); qcom_cpu_clk_msm8996_acd_init(cpuclk->clkr.regmap); - - /* - * Avoid overvolting. clk_core_set_rate_nolock() walks from top - * to bottom, so it will change the rate of the PLL before - * chaging the parent of PMUX. This can result in pmux getting - * clocked twice the expected rate. - * - * Manually switch to PLL/2 here. - */ - if (cnd->new_rate < DIV_2_THRESHOLD && - cnd->old_rate > DIV_2_THRESHOLD) - clk_cpu_8996_pmux_set_parent(&cpuclk->clkr.hw, SMUX_INDEX); - break; - case ABORT_RATE_CHANGE: - /* Revert manual change */ - if (cnd->new_rate < DIV_2_THRESHOLD && - cnd->old_rate > DIV_2_THRESHOLD) - clk_cpu_8996_pmux_set_parent(&cpuclk->clkr.hw, ACD_INDEX); + case POST_RATE_CHANGE: + if (cnd->new_rate < DIV_2_THRESHOLD) + ret = clk_cpu_8996_pmux_set_parent(&cpuclk->clkr.hw, + SMUX_INDEX); + else + ret = clk_cpu_8996_pmux_set_parent(&cpuclk->clkr.hw, + ACD_INDEX); break; default: + ret = 0; break; } - return NOTIFY_OK; + return notifier_from_errno(ret); }; static int qcom_cpu_clk_msm8996_driver_probe(struct platform_device *pdev) --- base-commit: c17e270dfb342a782d69c4a7c4c32980455afd9c change-id: 20251202-wip-obbardc-qcom-msm8096-clk-cpu-fix-downclock-b7561da4cb95 Best regards, -- Christopher Obbard <christopher.obbard(a)linaro.org>

5 days, 9 hours

3
9
0 0

[PATCH] block: fix partial IOVA mapping cleanup in blk_rq_dma_map_iova

by Chaitanya Kulkarni

When dma_iova_link() fails partway through mapping a request's bvec list, the function breaks out of the loop without cleaning up the already-mapped portions. Similarly, if dma_iova_sync() fails after all segments are linked, no cleanup is performed. This leaves the IOVA state partially mapped. The completion path (via dma_iova_destroy() or nvme_unmap_data()) then attempts to unmap the full expected size, but only a partial size was actually mapped. Fix by adding an out_unlink error path that calls dma_iova_destroy() to clean up any partial mapping before returning failure. The dma_iova_destroy() function handles both partial unlink and IOVA space freeing, and correctly handles the case where mapped_len is zero (first dma_iova_link() failed) by just freeing the IOVA allocation. This ensures that when an error occurs: 1. All partially-mapped IOVA ranges are properly unmapped 2. The IOVA address space is freed 3. The completion path won't attempt to unmap non-existent mappings Fixes: 858299dc6160 ("block: add scatterlist-less DMA mapping helpers") Cc: stable(a)vger.kernel.org Signed-off-by: Chaitanya Kulkarni <ckulkarnilinux(a)gmail.com> --- Hi Leon, Your last email is not accessible to me. Updated the patch description to explain dma_iova_destroy(). Please let me know for any issues you want me to fix before I send. -ck --- block/blk-mq-dma.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/block/blk-mq-dma.c b/block/blk-mq-dma.c index fb018fffffdc..feead1934301 100644 --- a/block/blk-mq-dma.c +++ b/block/blk-mq-dma.c @@ -126,17 +126,20 @@ static bool blk_rq_dma_map_iova(struct request *req, struct device *dma_dev, error = dma_iova_link(dma_dev, state, vec->paddr, mapped, vec->len, dir, attrs); if (error) - break; + goto out_unlink; mapped += vec->len; } while (blk_map_iter_next(req, &iter->iter, vec)); error = dma_iova_sync(dma_dev, state, 0, mapped); - if (error) { - iter->status = errno_to_blk_status(error); - return false; - } + if (error) + goto out_unlink; return true; + +out_unlink: + dma_iova_destroy(dma_dev, state, mapped, dir, attrs); + iter->status = errno_to_blk_status(error); + return false; } static inline void blk_rq_map_iter_init(struct request *rq, -- 2.40.0

5 days, 11 hours

1
0
0 0

[PATCH] parisc: kernel: replace kfree() with put_device() in create_tree_node()

by Haoxiang Li

If device_register() fails, put_device() is the correct way to drop the device reference. Found by code review. Fixes: 1070c9655b90 ("[PA-RISC] Fix must_check warnings in drivers.c") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- arch/parisc/kernel/drivers.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/parisc/kernel/drivers.c b/arch/parisc/kernel/drivers.c index 8d23fe42b0ce..809e3c171ad5 100644 --- a/arch/parisc/kernel/drivers.c +++ b/arch/parisc/kernel/drivers.c @@ -435,7 +435,7 @@ static struct parisc_device * __init create_tree_node(char id, dev->dev.dma_mask = &dev->dma_mask; dev->dev.coherent_dma_mask = dev->dma_mask; if (device_register(&dev->dev)) { - kfree(dev); + put_device(&dev->dev); return NULL; } -- 2.25.1

5 days, 12 hours

2
1
0 0

[PATCH 1/2] drm/nouveau/disp/nv50-: Set lock_core in curs507a_prepare

by Lyude Paul

For a while, I've been seeing a strange issue where some (usually not all) of the display DMA channels will suddenly hang, particularly when there is a visible cursor on the screen that is being frequently updated, and especially when said cursor happens to go between two screens. While this brings back lovely memories of fixing Intel Skylake bugs, I would quite like to fix it :). It turns out the problem that's happening here is that we're managing to reach nv50_head_flush_set() in our atomic commit path without actually holding nv50_disp->mutex. This means that cursor updates happening in parallel (along with any other atomic updates that need to use the core channel) will race with eachother, which eventually causes us to corrupt the pushbuffer - leading to a plethora of various GSP errors, usually: nouveau 0000:c1:00.0: gsp: Xid:56 CMDre 00000000 00000218 00102680 00000004 00800003 nouveau 0000:c1:00.0: gsp: Xid:56 CMDre 00000000 0000021c 00040509 00000004 00000001 nouveau 0000:c1:00.0: gsp: Xid:56 CMDre 00000000 00000000 00000000 00000001 00000001 The reason this is happening is because generally we check whether we need to set nv50_atom->lock_core at the end of nv50_head_atomic_check(). However, curs507a_prepare is called from the fb_prepare callback, which happens after the atomic check phase. As a result, this can lead to commits that both touch the core channel but also don't grab nv50_disp->mutex. So, fix this by making sure that we set nv50_atom->lock_core in cus507a_prepare(). Signed-off-by: Lyude Paul <lyude(a)redhat.com> Fixes: 1590700d94ac ("drm/nouveau/kms/nv50-: split each resource type into their own source files") Cc: <stable(a)vger.kernel.org> # v4.18+ --- drivers/gpu/drm/nouveau/dispnv50/curs507a.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c index a95ee5dcc2e39..1a889139cb053 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/curs507a.c +++ b/drivers/gpu/drm/nouveau/dispnv50/curs507a.c @@ -84,6 +84,7 @@ curs507a_prepare(struct nv50_wndw *wndw, struct nv50_head_atom *asyh, asyh->curs.handle = handle; asyh->curs.offset = offset; asyh->set.curs = asyh->curs.visible; + nv50_atom(asyh->state.state)->lock_core = true; } } -- 2.52.0

5 days, 13 hours

1
0
0 0

[PATCH] media: imagination: Fix value clamping in calculate_qp_tables

by Thorsten Blum

The local variable 'val' was never clamped to 1 or 255 because the return value of clamp() was not used. Fix this by assigning the clamped value back to 'val'. Cc: stable(a)vger.kernel.org Fixes: a1e294045885 ("media: imagination: Add E5010 JPEG Encoder driver") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- drivers/media/platform/imagination/e5010-jpeg-enc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/imagination/e5010-jpeg-enc.c b/drivers/media/platform/imagination/e5010-jpeg-enc.c index c4e0097cb8b7..a36a2acc896c 100644 --- a/drivers/media/platform/imagination/e5010-jpeg-enc.c +++ b/drivers/media/platform/imagination/e5010-jpeg-enc.c @@ -175,12 +175,12 @@ static void calculate_qp_tables(struct e5010_context *ctx) long long delta = v4l2_jpeg_ref_table_chroma_qt[i] * contrast + luminosity; int val = (int)(v4l2_jpeg_ref_table_chroma_qt[i] + delta); - clamp(val, 1, 255); + val = clamp(val, 1, 255); ctx->chroma_qp[i] = quality == -50 ? 1 : val; delta = v4l2_jpeg_ref_table_luma_qt[i] * contrast + luminosity; val = (int)(v4l2_jpeg_ref_table_luma_qt[i] + delta); - clamp(val, 1, 255); + val = clamp(val, 1, 255); ctx->luma_qp[i] = quality == -50 ? 1 : val; } -- Thorsten Blum <thorsten.blum(a)linux.dev> GPG: 1D60 735E 8AEF 3BE4 73B6 9D84 7336 78FD 8DFE EAD4

5 days, 13 hours

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror