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

[PATCH] bus: mhi: ep: Fix chained transfer handling in read path

by Sumit Kumar

From: Sumit Kumar <sumk(a)qti.qualcomm.com> The current implementation of mhi_ep_read_channel, in case of chained transactions, assumes the End of Transfer(EOT) bit is received with the doorbell. As a result, it may incorrectly advance mhi_chan->rd_offset beyond wr_offset during host-to-device transfers when EOT has not yet arrived. This can lead to access of unmapped host memory, causing IOMMU faults and processing of stale TREs. This change modifies the loop condition to ensure rd_offset remains behind wr_offset, allowing the function to process only valid TREs up to the current write pointer. This prevents premature reads and ensures safe traversal of chained TREs. Fixes: 5301258899773 ("bus: mhi: ep: Add support for reading from the host") Cc: stable(a)vger.kernel.org Co-developed-by: Akhil Vinod <akhvin(a)qti.qualcomm.com> Signed-off-by: Akhil Vinod <akhvin(a)qti.qualcomm.com> Signed-off-by: Sumit Kumar <sumk(a)qti.qualcomm.com> --- drivers/bus/mhi/ep/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bus/mhi/ep/main.c b/drivers/bus/mhi/ep/main.c index b3eafcf2a2c50d95e3efd3afb27038ecf55552a5..2e134f44952d1070c62c24aeca9effc7fd325860 100644 --- a/drivers/bus/mhi/ep/main.c +++ b/drivers/bus/mhi/ep/main.c @@ -468,7 +468,7 @@ static int mhi_ep_read_channel(struct mhi_ep_cntrl *mhi_cntrl, mhi_chan->rd_offset = (mhi_chan->rd_offset + 1) % ring->ring_size; } - } while (buf_left && !tr_done); + } while (buf_left && !tr_done && mhi_chan->rd_offset != ring->wr_offset); return 0; --- base-commit: 4c06e63b92038fadb566b652ec3ec04e228931e8 change-id: 20250709-chained_transfer-0b95f8afa487 Best regards, -- Sumit Kumar <quic_sumk(a)quicinc.com>

3 months, 1 week

4
6
0 0

[PATCH 1/2] rpmsg: glink_native: fix rpmsg device leak

by srinivas.kandagatla＠oss.qualcomm.com

From: Srinivas Kandagatla <srinivas.kandagatla(a)oss.qualcomm.com> While testing rpmsg-char interface it was noticed that duplicate sysfs entries are getting created and below warning is noticed. Reason for this is that we are leaking rpmsg device pointer, setting it null without actually unregistering device. Any further attempts to unregister fail because rpdev is NULL, resulting in a leak. Fix this by unregistering rpmsg device before removing its reference from rpmsg channel. sysfs: cannot create duplicate filename '/devices/platform/soc(a)0/3700000.remot eproc/remoteproc/remoteproc1/3700000.remoteproc:glink-edge/3700000.remoteproc: glink-edge.adsp_apps.-1.-1' [ 114.115347] CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.16.0-rc4 #7 PREEMPT [ 114.115355] Hardware name: Qualcomm Technologies, Inc. Robotics RB3gen2 (DT) [ 114.115358] Workqueue: events qcom_glink_work [ 114.115371] Call trace:8 [ 114.115374] show_stack+0x18/0x24 (C) [ 114.115382] dump_stack_lvl+0x60/0x80 [ 114.115388] dump_stack+0x18/0x24 [ 114.115393] sysfs_warn_dup+0x64/0x80 [ 114.115402] sysfs_create_dir_ns+0xf4/0x120 [ 114.115409] kobject_add_internal+0x98/0x260 [ 114.115416] kobject_add+0x9c/0x108 [ 114.115421] device_add+0xc4/0x7a0 [ 114.115429] rpmsg_register_device+0x5c/0xb0 [ 114.115434] qcom_glink_work+0x4bc/0x820 [ 114.115438] process_one_work+0x148/0x284 [ 114.115446] worker_thread+0x2c4/0x3e0 [ 114.115452] kthread+0x12c/0x204 [ 114.115457] ret_from_fork+0x10/0x20 [ 114.115464] kobject: kobject_add_internal failed for 3700000.remoteproc: glink-edge.adsp_apps.-1.-1 with -EEXIST, don't try to register things with the same name in the same directory. [ 114.250045] rpmsg 3700000.remoteproc:glink-edge.adsp_apps.-1.-1: device_add failed: -17 Fixes: 835764ddd9af ("rpmsg: glink: Move the common glink protocol implementation to glink_native.c") Cc: <Stable(a)vger.kernel.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla(a)oss.qualcomm.com> --- drivers/rpmsg/qcom_glink_native.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/rpmsg/qcom_glink_native.c b/drivers/rpmsg/qcom_glink_native.c index 820a6ca5b1d7..3a15d9d10808 100644 --- a/drivers/rpmsg/qcom_glink_native.c +++ b/drivers/rpmsg/qcom_glink_native.c @@ -1399,6 +1399,7 @@ static void qcom_glink_destroy_ept(struct rpmsg_endpoint *ept) { struct glink_channel *channel = to_glink_channel(ept); struct qcom_glink *glink = channel->glink; + struct rpmsg_channel_info chinfo; unsigned long flags; spin_lock_irqsave(&channel->recv_lock, flags); @@ -1406,6 +1407,13 @@ static void qcom_glink_destroy_ept(struct rpmsg_endpoint *ept) spin_unlock_irqrestore(&channel->recv_lock, flags); /* Decouple the potential rpdev from the channel */ + if (channel->rpdev) { + strscpy_pad(chinfo.name, channel->name, sizeof(chinfo.name)); + chinfo.src = RPMSG_ADDR_ANY; + chinfo.dst = RPMSG_ADDR_ANY; + + rpmsg_unregister_device(glink->dev, &chinfo); + } channel->rpdev = NULL; qcom_glink_send_close_req(glink, channel); -- 2.50.0

3 months, 1 week

2
1
0 0

HYSTOU Mini PC

by Britney

3 months, 1 week

1
0
0 0

[PATCH v6.6 RESEND 0/2] x86/irq: Plug vector setup race

by Jinjie Ruan

There is a vector setup race, which overwrites the interrupt descriptor in the per CPU vector array resulting in a disfunctional device. CPU0 CPU1 interrupt is raised in APIC IRR but not handled free_irq() per_cpu(vector_irq, CPU1)[vector] = VECTOR_SHUTDOWN; request_irq() common_interrupt() d = this_cpu_read(vector_irq[vector]); per_cpu(vector_irq, CPU1)[vector] = desc; if (d == VECTOR_SHUTDOWN) this_cpu_write(vector_irq[vector], VECTOR_UNUSED); free_irq() cannot observe the pending vector in the CPU1 APIC as there is no way to query the remote CPUs APIC IRR. This requires that request_irq() uses the same vector/CPU as the one which was freed, but this also can be triggered by a spurious interrupt. Interestingly enough this problem managed to be hidden for more than a decade. Prevent this by reevaluating vector_irq under the vector lock, which is held by the interrupt activation code when vector_irq is updated. The first patch provides context for subsequent real bugfix patch. Fixes: 9345005f4eed ("x86/irq: Fix do_IRQ() interrupt warning for cpu hotplug retriggered irqs") Cc: stable(a)vger.kernel.org#6.6.x Cc: gregkh(a)linuxfoundation.org v1 -> RESEND - Add upstream commit ID. Jacob Pan (1): x86/irq: Factor out handler invocation from common_interrupt() Thomas Gleixner (1): x86/irq: Plug vector setup race arch/x86/kernel/irq.c | 70 ++++++++++++++++++++++++++++++++++--------- 1 file changed, 56 insertions(+), 14 deletions(-) -- 2.34.1

3 months, 1 week

2
6
0 0

[PATCH v2 1/3] dt-bindings: reset: Scope the compatible to VO subsystem explicitly

by Yao Zi

The reset controller driver for the TH1520 was using the generic compatible string "thead,th1520-reset". However, the controller described by this compatible only manages the resets for the Video Output (VO) subsystem. Using a generic compatible is confusing as it implies control over all reset units on the SoC. This could lead to conflicts if support for other reset controllers on the TH1520 is added in the future like AP. Let's introduce a new compatible string, "thead,th1520-reset-vo", to explicitly scope the controller to VO-subsystem. The old one is marked as deprecated. Fixes: 30e7573babdc ("dt-bindings: reset: Add T-HEAD TH1520 SoC Reset Controller") Cc: stable(a)vger.kernel.org Reported-by: Icenowy Zheng <uwu(a)icenowy.me> Co-developed-by: Michal Wilczynski <m.wilczynski(a)samsung.com> Signed-off-by: Michal Wilczynski <m.wilczynski(a)samsung.com> Signed-off-by: Yao Zi <ziyao(a)disroot.org> --- .../bindings/reset/thead,th1520-reset.yaml | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml b/Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml index f2e91d0add7a..3930475dcc04 100644 --- a/Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml +++ b/Documentation/devicetree/bindings/reset/thead,th1520-reset.yaml @@ -15,8 +15,11 @@ maintainers: properties: compatible: - enum: - - thead,th1520-reset + oneOf: + - enum: + - thead,th1520-reset-vo + - const: thead,th1520-reset + deprecated: true reg: maxItems: 1 @@ -33,12 +36,8 @@ additionalProperties: false examples: - | - soc { - #address-cells = <2>; - #size-cells = <2>; - rst: reset-controller@ffef528000 { - compatible = "thead,th1520-reset"; - reg = <0xff 0xef528000 0x0 0x1000>; + reset-controller@ffef528000 { + compatible = "thead,th1520-reset-vo"; + reg = <0xef528000 0x1000>; #reset-cells = <1>; - }; }; -- 2.50.1

3 months, 1 week

2
3
0 0

[PATCH v2 03/16] drm/xe/vm: Clear the scratch_pt pointer on error

by Thomas Hellström

Avoid triggering a dereference of an error pointer on cleanup in xe_vm_free_scratch() by clearing any scratch_pt error pointer. Fixes: 06951c2ee72d ("drm/xe: Use NULL PTEs as scratch PTEs") Cc: Brian Welty <brian.welty(a)intel.com> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Lucas De Marchi <lucas.demarchi(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.8+ Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost(a)intel.com> --- drivers/gpu/drm/xe/xe_vm.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/xe/xe_vm.c b/drivers/gpu/drm/xe/xe_vm.c index f35d69c0b4c6..529b6767caac 100644 --- a/drivers/gpu/drm/xe/xe_vm.c +++ b/drivers/gpu/drm/xe/xe_vm.c @@ -1635,8 +1635,12 @@ static int xe_vm_create_scratch(struct xe_device *xe, struct xe_tile *tile, for (i = MAX_HUGEPTE_LEVEL; i < vm->pt_root[id]->level; i++) { vm->scratch_pt[id][i] = xe_pt_create(vm, tile, i); - if (IS_ERR(vm->scratch_pt[id][i])) - return PTR_ERR(vm->scratch_pt[id][i]); + if (IS_ERR(vm->scratch_pt[id][i])) { + int err = PTR_ERR(vm->scratch_pt[id][i]); + + vm->scratch_pt[id][i] = NULL; + return err; + } xe_pt_populate_empty(tile, vm, vm->scratch_pt[id][i]); } -- 2.50.1

3 months, 1 week

1
0
0 0

[PATCH v2 2/2] drm/amd/display: fix leak of probed modes

by Fedor Pchelkin

amdgpu_dm_connector_ddc_get_modes() reinitializes a connector's probed modes list without cleaning it up. First time it is called during the driver's initialization phase, then via drm_mode_getconnector() ioctl. The leaks observed with Kmemleak are as following: unreferenced object 0xffff88812f91b200 (size 128): comm "(udev-worker)", pid 388, jiffies 4294695475 hex dump (first 32 bytes): ac dd 07 00 80 02 70 0b 90 0b e0 0b 00 00 e0 01 ......p......... 0b 07 10 07 5c 07 00 00 0a 00 00 00 00 00 00 00 ....\........... backtrace (crc 89db554f): __kmalloc_cache_noprof+0x3a3/0x490 drm_mode_duplicate+0x8e/0x2b0 amdgpu_dm_create_common_mode+0x40/0x150 [amdgpu] amdgpu_dm_connector_add_common_modes+0x336/0x488 [amdgpu] amdgpu_dm_connector_get_modes+0x428/0x8a0 [amdgpu] amdgpu_dm_initialize_drm_device+0x1389/0x17b4 [amdgpu] amdgpu_dm_init.cold+0x157b/0x1a1e [amdgpu] dm_hw_init+0x3f/0x110 [amdgpu] amdgpu_device_ip_init+0xcf4/0x1180 [amdgpu] amdgpu_device_init.cold+0xb84/0x1863 [amdgpu] amdgpu_driver_load_kms+0x15/0x90 [amdgpu] amdgpu_pci_probe+0x391/0xce0 [amdgpu] local_pci_probe+0xd9/0x190 pci_call_probe+0x183/0x540 pci_device_probe+0x171/0x2c0 really_probe+0x1e1/0x890 Found by Linux Verification Center (linuxtesting.org). Fixes: acc96ae0d127 ("drm/amd/display: set panel orientation before drm_dev_register") Cc: stable(a)vger.kernel.org Signed-off-by: Fedor Pchelkin <pchelkin(a)ispras.ru> --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index cd0e2976e268..7ec1f9afc081 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -8227,9 +8227,12 @@ static void amdgpu_dm_connector_ddc_get_modes(struct drm_connector *connector, { struct amdgpu_dm_connector *amdgpu_dm_connector = to_amdgpu_dm_connector(connector); + struct drm_display_mode *mode, *t; if (drm_edid) { /* empty probed_modes */ + list_for_each_entry_safe(mode, t, &connector->probed_modes, head) + drm_mode_remove(connector, mode); INIT_LIST_HEAD(&connector->probed_modes); amdgpu_dm_connector->num_modes = drm_edid_connector_add_modes(connector); -- 2.50.1

3 months, 1 week

2
2
0 0

[PATCH v6.6 0/2] x86/irq: Plug vector setup race

by Jinjie Ruan

There is a vector setup race, which overwrites the interrupt descriptor in the per CPU vector array resulting in a disfunctional device. CPU0 CPU1 interrupt is raised in APIC IRR but not handled free_irq() per_cpu(vector_irq, CPU1)[vector] = VECTOR_SHUTDOWN; request_irq() common_interrupt() d = this_cpu_read(vector_irq[vector]); per_cpu(vector_irq, CPU1)[vector] = desc; if (d == VECTOR_SHUTDOWN) this_cpu_write(vector_irq[vector], VECTOR_UNUSED); free_irq() cannot observe the pending vector in the CPU1 APIC as there is no way to query the remote CPUs APIC IRR. This requires that request_irq() uses the same vector/CPU as the one which was freed, but this also can be triggered by a spurious interrupt. Interestingly enough this problem managed to be hidden for more than a decade. Prevent this by reevaluating vector_irq under the vector lock, which is held by the interrupt activation code when vector_irq is updated. Fixes: 9345005f4eed ("x86/irq: Fix do_IRQ() interrupt warning for cpu hotplug retriggered irqs") Cc: stable(a)vger.kernel.org#6.6.x Cc: gregkh(a)linuxfoundation.org Jacob Pan (1): x86/irq: Factor out handler invocation from common_interrupt() Thomas Gleixner (1): x86/irq: Plug vector setup race arch/x86/kernel/irq.c | 70 ++++++++++++++++++++++++++++++++++--------- 1 file changed, 56 insertions(+), 14 deletions(-) -- 2.34.1

3 months, 1 week

3
5
0 0

FAILED: patch "[PATCH] btrfs: don't skip remaining extrefs if dir not found during" failed to apply to 6.6-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.6-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.6.y git checkout FETCH_HEAD git cherry-pick -x 24e066ded45b8147b79c7455ac43a5bff7b5f378 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025081818-rimless-financial-6942@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 24e066ded45b8147b79c7455ac43a5bff7b5f378 Mon Sep 17 00:00:00 2001 From: Filipe Manana <fdmanana(a)suse.com> Date: Fri, 11 Jul 2025 20:48:23 +0100 Subject: [PATCH] btrfs: don't skip remaining extrefs if dir not found during log replay During log replay, at add_inode_ref(), if we have an extref item that contains multiple extrefs and one of them points to a directory that does not exist in the subvolume tree, we are supposed to ignore it and process the remaining extrefs encoded in the extref item, since each extref can point to a different parent inode. However when that happens we just return from the function and ignore the remaining extrefs. The problem has been around since extrefs were introduced, in commit f186373fef00 ("btrfs: extended inode refs"), but it's hard to hit in practice because getting extref items encoding multiple extref requires getting a hash collision when computing the offset of the extref's key. The offset if computed like this: key.offset = btrfs_extref_hash(dir_ino, name->name, name->len); and btrfs_extref_hash() is just a wrapper around crc32c(). Fix this by moving to next iteration of the loop when we don't find the parent directory that an extref points to. Fixes: f186373fef00 ("btrfs: extended inode refs") CC: stable(a)vger.kernel.org # 6.1+ Reviewed-by: Boris Burkov <boris(a)bur.io> Signed-off-by: Filipe Manana <fdmanana(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c index e3c77f3d092c..467b69a4ef3b 100644 --- a/fs/btrfs/tree-log.c +++ b/fs/btrfs/tree-log.c @@ -1433,6 +1433,8 @@ static noinline int add_inode_ref(struct btrfs_trans_handle *trans, if (log_ref_ver) { ret = extref_get_fields(eb, ref_ptr, &name, &ref_index, &parent_objectid); + if (ret) + goto out; /* * parent object can change from one array * item to another. @@ -1449,16 +1451,23 @@ static noinline int add_inode_ref(struct btrfs_trans_handle *trans, * the loop when getting the first * parent dir. */ - if (ret == -ENOENT) + if (ret == -ENOENT) { + /* + * The next extref may refer to + * another parent dir that + * exists, so continue. + */ ret = 0; + goto next; + } goto out; } } } else { ret = ref_get_fields(eb, ref_ptr, &name, &ref_index); + if (ret) + goto out; } - if (ret) - goto out; ret = inode_in_dir(root, path, btrfs_ino(dir), btrfs_ino(inode), ref_index, &name); @@ -1492,10 +1501,11 @@ static noinline int add_inode_ref(struct btrfs_trans_handle *trans, } /* Else, ret == 1, we already have a perfect match, we're done. */ +next: ref_ptr = (unsigned long)(ref_ptr + ref_struct_size) + name.len; kfree(name.name); name.name = NULL; - if (log_ref_ver) { + if (log_ref_ver && dir) { iput(&dir->vfs_inode); dir = NULL; }

3 months, 1 week

3
2
0 0

Re: Patch "can: ti_hecc: fix -Woverflow compiler warning" has been added to the 6.15-stable tree

by Vincent Mailhol

Hi Sasha, On Sun. 17 Aug. 2025 at 22:49, Sasha Levin <sashal(a)kernel.org> wrote: > > This is a note to let you know that I've just added the patch titled > > can: ti_hecc: fix -Woverflow compiler warning > > to the 6.15-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: > can-ti_hecc-fix-woverflow-compiler-warning.patch > and it can be found in the queue-6.15 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. This only silences a compiler warning. There are no actual bugs in the original code. This is why I did not put the Fixes tag. I am not against this being backported to stable but please note that this depends on the new BIT_U32() macro which where recently added in commit 5b572e8a9f3d ("bits: introduce fixed-type BIT_U*()") Link: https://git.kernel.org/torvalds/c/5b572e8a9f3d So, unless you also backport the above patch, this will not compile. The options are: 1. drop this patch (i.e. keep that benin -Woverflow in stable) 2. backport the new BIT_U*() macros and keep the patch as-is 3. modify the patch as below: mbx_mask = ~(u32)BIT(HECC_RX_LAST_MBOX); I'll let you decide what you prefer. That comment also applies to the other backports of that patch except for the 6.16.x branch which already has the BIT_U*() macros. Yours sincerely, Vincent Mailhol > commit f37dbcbbea3844900081b44f372f2f4d4be1b5c6 > Author: Vincent Mailhol <mailhol.vincent(a)wanadoo.fr> > Date: Tue Jul 15 20:28:11 2025 +0900 > > can: ti_hecc: fix -Woverflow compiler warning > > [ Upstream commit 7cae4d04717b002cffe41169da3f239c845a0723 ] > > Fix below default (W=0) warning: > > drivers/net/can/ti_hecc.c: In function 'ti_hecc_start': > drivers/net/can/ti_hecc.c:386:20: warning: conversion from 'long unsigned int' to 'u32' {aka 'unsigned int'} changes value from '18446744073709551599' to '4294967279' [-Woverflow] > 386 | mbx_mask = ~BIT(HECC_RX_LAST_MBOX); > | ^ > > Signed-off-by: Vincent Mailhol <mailhol.vincent(a)wanadoo.fr> > Link: https://patch.msgid.link/20250715-can-compile-test-v2-1-f7fd566db86f@wanado… > Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c > index 644e8b8eb91e..e6d6661a908a 100644 > --- a/drivers/net/can/ti_hecc.c > +++ b/drivers/net/can/ti_hecc.c > @@ -383,7 +383,7 @@ static void ti_hecc_start(struct net_device *ndev) > * overflows instead of the hardware silently dropping the > * messages. > */ > - mbx_mask = ~BIT(HECC_RX_LAST_MBOX); > + mbx_mask = ~BIT_U32(HECC_RX_LAST_MBOX); > hecc_write(priv, HECC_CANOPC, mbx_mask); > > /* Enable interrupts */

3 months, 1 week

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror