December 2024 - Linux-stable-mirror

[PATCH 1/6] pps: fix cdev use-after-free

by Michal Schmidt

The lifetime of a struct pps_device and the struct cdev embedded in it is under control of the associated struct device. The cdev's .open/.release methods (pps_cdev_{open,release}()) try to keep the device alive while the cdev is open, but this is insufficient. Consider this sequence: 1. Attach the PPS line discipline to a TTY. 2. Open the created /dev/pps* file. 3. Detach the PPS line discipline. 4. Close the file. In this scenario, the last reference to the cdev is not released from pps code, but in __fput(), *after* running the .release method, which frees the pps_device (including struct cdev). Fix this by using cdev_set_parent() to ensure that the pps_device outlives the cdev. cdev_set_parent() should be used before cdev_add(), but we can't do that here, because at that point we don't have the dev yet. It's created in the next step with device_create(). To compensate, bump the refcount of the dev, which is what cdev_add() would have done if we followed the usual order. This will be cleaned up in subsequent patches. With the parent relationship in place, the .open/.release methods no longer need to change the refcount. The cdev reference held by the core filesystem code is enough to keep the pps device alive. The .release method had nothing else to do, so remove it. Move the cdev_del() from pps_device_destruct() to pps_unregister_cdev(). This is necessary. Otherwise, the pps_device would be holding a reference to itself and never get released. It also brings symmetry between pps_register_cdev() and pps_unregister_cdev(). KASAN detection of the bug: pps_core: deallocating pps0 ================================================================== BUG: KASAN: slab-use-after-free in cdev_put+0x4e/0x50 Read of size 8 at addr ff1100001c1c7360 by task sleep/1192 CPU: 0 UID: 0 PID: 1192 Comm: sleep Not tainted 6.12.0-0.rc7.59.fc42.x86_64+debug #1 Hardware name: Red Hat OpenStack Compute, BIOS 1.14.0-1.module+el8.4.0+8855+a9e237a9 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x84/0xd0 print_report+0x174/0x505 kasan_report+0xab/0x180 cdev_put+0x4e/0x50 __fput+0x725/0xaa0 task_work_run+0x119/0x200 do_exit+0x8ef/0x27a0 do_group_exit+0xbc/0x250 get_signal+0x1b78/0x1e00 arch_do_signal_or_restart+0x8f/0x570 syscall_exit_to_user_mode+0x1f4/0x290 do_syscall_64+0xa3/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f6c598342d6 Code: Unable to access opcode bytes at 0x7f6c598342ac. RSP: 002b:00007ffff3528160 EFLAGS: 00000202 ORIG_RAX: 00000000000000e6 RAX: fffffffffffffdfc RBX: 00007f6c597c5740 RCX: 00007f6c598342d6 RDX: 00007ffff35281f0 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00007ffff3528170 R08: 0000000000000000 R09: 0000000000000000 R10: 00007ffff35281e0 R11: 0000000000000202 R12: 00007f6c597c56c8 R13: 00007ffff35281e0 R14: 000000000000003c R15: 00007ffff35281e0 </TASK> Allocated by task 1186: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 pps_register_source+0xe4/0x360 pps_tty_open+0x191/0x220 [pps_ldisc] tty_ldisc_open+0x75/0xc0 tty_set_ldisc+0x29e/0x730 tty_ioctl+0x866/0x11e0 __x64_sys_ioctl+0x12e/0x1a0 do_syscall_64+0x97/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 1192: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x37/0x50 kfree+0x140/0x4d0 device_release+0x9c/0x210 kobject_put+0x17c/0x4b0 pps_cdev_release+0x56/0x70 __fput+0x368/0xaa0 task_work_run+0x119/0x200 do_exit+0x8ef/0x27a0 do_group_exit+0xbc/0x250 get_signal+0x1b78/0x1e00 arch_do_signal_or_restart+0x8f/0x570 syscall_exit_to_user_mode+0x1f4/0x290 do_syscall_64+0xa3/0x190 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ff1100001c1c7200 which belongs to the cache kmalloc-rnd-02-512 of size 512 The buggy address is located 352 bytes inside of freed 512-byte region [ff1100001c1c7200, ff1100001c1c7400) [...] ================================================================== Fixes: eae9d2ba0cfc ("LinuxPPS: core support") Fixes: d953e0e837e6 ("pps: Fix a use-after free bug when unregistering a source.") Cc: stable(a)vger.kernel.org Signed-off-by: Michal Schmidt <mschmidt(a)redhat.com> --- drivers/pps/pps.c | 17 +++++------------ 1 file changed, 5 insertions(+), 12 deletions(-) diff --git a/drivers/pps/pps.c b/drivers/pps/pps.c index 25d47907db17..4f497353daa2 100644 --- a/drivers/pps/pps.c +++ b/drivers/pps/pps.c @@ -301,15 +301,6 @@ static int pps_cdev_open(struct inode *inode, struct file *file) struct pps_device *pps = container_of(inode->i_cdev, struct pps_device, cdev); file->private_data = pps; - kobject_get(&pps->dev->kobj); - return 0; -} - -static int pps_cdev_release(struct inode *inode, struct file *file) -{ - struct pps_device *pps = container_of(inode->i_cdev, - struct pps_device, cdev); - kobject_put(&pps->dev->kobj); return 0; } @@ -324,15 +315,12 @@ static const struct file_operations pps_cdev_fops = { .compat_ioctl = pps_cdev_compat_ioctl, .unlocked_ioctl = pps_cdev_ioctl, .open = pps_cdev_open, - .release = pps_cdev_release, }; static void pps_device_destruct(struct device *dev) { struct pps_device *pps = dev_get_drvdata(dev); - cdev_del(&pps->cdev); - /* Now we can release the ID for re-use */ pr_debug("deallocating pps%d\n", pps->id); mutex_lock(&pps_idr_lock); @@ -383,6 +371,10 @@ int pps_register_cdev(struct pps_device *pps) goto del_cdev; } + cdev_set_parent(&pps->cdev, &pps->dev->kobj); + /* Compensate for setting the parent after cdev_add() */ + get_device(pps->dev); + /* Override the release function with our own */ pps->dev->release = pps_device_destruct; @@ -407,6 +399,7 @@ void pps_unregister_cdev(struct pps_device *pps) pr_debug("unregistering pps%d\n", pps->id); pps->lookup_cookie = NULL; device_destroy(pps_class, pps->dev->devt); + cdev_del(&pps->cdev); } /* -- 2.47.0

9 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] fcntl: make F_DUPFD_QUERY associative" failed to apply to 6.11-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.11-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.11.y git checkout FETCH_HEAD git cherry-pick -x 2714b0d1f36999dbd99a3474a24e7301acbd74f1 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024120203-carat-landlord-afcf@gregkh' --subject-prefix 'PATCH 6.11.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 2714b0d1f36999dbd99a3474a24e7301acbd74f1 Mon Sep 17 00:00:00 2001 From: Christian Brauner <brauner(a)kernel.org> Date: Tue, 8 Oct 2024 13:30:49 +0200 Subject: [PATCH] fcntl: make F_DUPFD_QUERY associative Currently when passing a closed file descriptor to fcntl(fd, F_DUPFD_QUERY, fd_dup) the order matters: fd = open("/dev/null"); fd_dup = dup(fd); When we now close one of the file descriptors we get: (1) fcntl(fd, fd_dup) // -EBADF (2) fcntl(fd_dup, fd) // 0 aka not equal depending on which file descriptor is passed first. That's not a huge deal but it gives the api I slightly weird feel. Make it so that the order doesn't matter by requiring that both file descriptors are valid: (1') fcntl(fd, fd_dup) // -EBADF (2') fcntl(fd_dup, fd) // -EBADF Link: https://lore.kernel.org/r/20241008-duften-formel-251f967602d5@brauner Fixes: c62b758bae6a ("fcntl: add F_DUPFD_QUERY fcntl()") Reviewed-by: Jeff Layton <jlayton(a)kernel.org> Reviewed-By: Lennart Poettering <lennart(a)poettering.net> Cc: stable(a)vger.kernel.org Reported-by: Lennart Poettering <lennart(a)poettering.net> Signed-off-by: Christian Brauner <brauner(a)kernel.org> diff --git a/fs/fcntl.c b/fs/fcntl.c index 22dd9dcce7ec..3d89de31066a 100644 --- a/fs/fcntl.c +++ b/fs/fcntl.c @@ -397,6 +397,9 @@ static long f_dupfd_query(int fd, struct file *filp) { CLASS(fd_raw, f)(fd); + if (fd_empty(f)) + return -EBADF; + /* * We can do the 'fdput()' immediately, as the only thing that * matters is the pointer value which isn't changed by the fdput.

9 months, 2 weeks

1
0
0 0

[PATCH v2] kbuild: Move -Wenum-enum-conversion to W=2

by Nathan Chancellor

-Wenum-enum-conversion was strengthened in clang-19 to warn for C, which caused the kernel to move it to W=1 in commit 75b5ab134bb5 ("kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1") because there were numerous instances that would break builds with -Werror. Unfortunately, this is not a full solution, as more and more developers, subsystems, and distributors are building with W=1 as well, so they continue to see the numerous instances of this warning. Since the move to W=1, there have not been many new instances that have appeared through various build reports and the ones that have appeared seem to be following similar existing patterns, suggesting that most instances of this warning will not be real issues. The only alternatives for silencing this warning are adding casts (which is generally seen as an ugly practice) or refactoring the enums to macro defines or a unified enum (which may be undesirable because of type safety in other parts of the code). Move the warning to W=2, where warnings that occur frequently but may be relevant should reside. Cc: stable(a)vger.kernel.org Fixes: 75b5ab134bb5 ("kbuild: Move -Wenum-{compare-conditional,enum-conversion} into W=1") Link: https://lore.kernel.org/ZwRA9SOcOjjLJcpi@google.com/ Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- Changes in v2: - Move -Wenum-enum-conversion to W=2, instead of disabling it outright (Arnd) - Leave -Wenum-compare-conditional in W=1, as there are not that many instances, so it can be turned on fully at some point (Arnd) - Link to v1: https://lore.kernel.org/r/20241016-disable-two-clang-enum-warnings-v1-1-ae8… --- scripts/Makefile.extrawarn | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/scripts/Makefile.extrawarn b/scripts/Makefile.extrawarn index 1d13cecc7cc7808610e635ddc03476cf92b3a8c1..04faf15ed316a9c291dc952b6cc40fb6c8c330cf 100644 --- a/scripts/Makefile.extrawarn +++ b/scripts/Makefile.extrawarn @@ -130,7 +130,6 @@ KBUILD_CFLAGS += $(call cc-disable-warning, pointer-to-enum-cast) KBUILD_CFLAGS += -Wno-tautological-constant-out-of-range-compare KBUILD_CFLAGS += $(call cc-disable-warning, unaligned-access) KBUILD_CFLAGS += -Wno-enum-compare-conditional -KBUILD_CFLAGS += -Wno-enum-enum-conversion endif endif @@ -154,6 +153,10 @@ KBUILD_CFLAGS += -Wno-missing-field-initializers KBUILD_CFLAGS += -Wno-type-limits KBUILD_CFLAGS += -Wno-shift-negative-value +ifdef CONFIG_CC_IS_CLANG +KBUILD_CFLAGS += -Wno-enum-enum-conversion +endif + ifdef CONFIG_CC_IS_GCC KBUILD_CFLAGS += -Wno-maybe-uninitialized endif --- base-commit: 8e929cb546ee42c9a61d24fae60605e9e3192354 change-id: 20241016-disable-two-clang-enum-warnings-e7994d44f948 Best regards, -- Nathan Chancellor <nathan(a)kernel.org>

9 months, 2 weeks

2
2
0 0

[PATCH] arm64: dts: qcom: sa8775p: Fix the size of 'addr_space' regions

by Manivannan Sadhasivam

For both the controller instances, size of the 'addr_space' region should be 0x1fe00000 as per the hardware memory layout. Otherwise, endpoint drivers cannot request even reasonable BAR size of 1MB. Cc: stable(a)vger.kernel.org # 6.11 Fixes: c5f5de8434ec ("arm64: dts: qcom: sa8775p: Add ep pcie1 controller node") Fixes: 1924f5518224 ("arm64: dts: qcom: sa8775p: Add ep pcie0 controller node") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam(a)linaro.org> --- arch/arm64/boot/dts/qcom/sa8775p.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/qcom/sa8775p.dtsi b/arch/arm64/boot/dts/qcom/sa8775p.dtsi index e8dbc8d820a6..320a94dcac5c 100644 --- a/arch/arm64/boot/dts/qcom/sa8775p.dtsi +++ b/arch/arm64/boot/dts/qcom/sa8775p.dtsi @@ -5587,7 +5587,7 @@ pcie0_ep: pcie-ep@1c00000 { <0x0 0x40000000 0x0 0xf20>, <0x0 0x40000f20 0x0 0xa8>, <0x0 0x40001000 0x0 0x4000>, - <0x0 0x40200000 0x0 0x100000>, + <0x0 0x40200000 0x0 0x1fe00000>, <0x0 0x01c03000 0x0 0x1000>, <0x0 0x40005000 0x0 0x2000>; reg-names = "parf", "dbi", "elbi", "atu", "addr_space", @@ -5744,7 +5744,7 @@ pcie1_ep: pcie-ep@1c10000 { <0x0 0x60000000 0x0 0xf20>, <0x0 0x60000f20 0x0 0xa8>, <0x0 0x60001000 0x0 0x4000>, - <0x0 0x60200000 0x0 0x100000>, + <0x0 0x60200000 0x0 0x1fe00000>, <0x0 0x01c13000 0x0 0x1000>, <0x0 0x60005000 0x0 0x2000>; reg-names = "parf", "dbi", "elbi", "atu", "addr_space", -- 2.25.1

9 months, 2 weeks

3
2
0 0

FAILED: patch "[PATCH] xhci: Fix control transfer error on Etron xHCI host" 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 5e1c67abc9301d05130b7e267c204e7005503b33 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024120248-scuff-roster-854c@gregkh' --subject-prefix 'PATCH 6.6.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5e1c67abc9301d05130b7e267c204e7005503b33 Mon Sep 17 00:00:00 2001 From: Kuangyi Chiang <ki.chiang65(a)gmail.com> Date: Wed, 6 Nov 2024 12:14:45 +0200 Subject: [PATCH] xhci: Fix control transfer error on Etron xHCI host Performing a stability stress test on a USB3.0 2.5G ethernet adapter results in errors like this: [ 91.441469] r8152 2-3:1.0 eth3: get_registers -71 [ 91.458659] r8152 2-3:1.0 eth3: get_registers -71 [ 91.475911] r8152 2-3:1.0 eth3: get_registers -71 [ 91.493203] r8152 2-3:1.0 eth3: get_registers -71 [ 91.510421] r8152 2-3:1.0 eth3: get_registers -71 The r8152 driver will periodically issue lots of control-IN requests to access the status of ethernet adapter hardware registers during the test. This happens when the xHCI driver enqueue a control TD (which cross over the Link TRB between two ring segments, as shown) in the endpoint zero's transfer ring. Seems the Etron xHCI host can not perform this TD correctly, causing the USB transfer error occurred, maybe the upper driver retry that control-IN request can solve problem, but not all drivers do this. | | ------- | TRB | Setup Stage ------- | TRB | Link ------- ------- | TRB | Data Stage ------- | TRB | Status Stage ------- | | To work around this, the xHCI driver should enqueue a No Op TRB if next available TRB is the Link TRB in the ring segment, this can prevent the Setup and Data Stage TRB to be breaked by the Link TRB. Check if the XHCI_ETRON_HOST quirk flag is set before invoking the workaround in xhci_queue_ctrl_tx(). Fixes: d0e96f5a71a0 ("USB: xhci: Control transfer support.") Cc: stable(a)vger.kernel.org Signed-off-by: Kuangyi Chiang <ki.chiang65(a)gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Link: https://lore.kernel.org/r/20241106101459.775897-20-mathias.nyman@linux.inte… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index f62b243d0fc4..517df97ef496 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -3733,6 +3733,20 @@ int xhci_queue_ctrl_tx(struct xhci_hcd *xhci, gfp_t mem_flags, if (!urb->setup_packet) return -EINVAL; + if ((xhci->quirks & XHCI_ETRON_HOST) && + urb->dev->speed >= USB_SPEED_SUPER) { + /* + * If next available TRB is the Link TRB in the ring segment then + * enqueue a No Op TRB, this can prevent the Setup and Data Stage + * TRB to be breaked by the Link TRB. + */ + if (trb_is_link(ep_ring->enqueue + 1)) { + field = TRB_TYPE(TRB_TR_NOOP) | ep_ring->cycle_state; + queue_trb(xhci, ep_ring, false, 0, 0, + TRB_INTR_TARGET(0), field); + } + } + /* 1 TRB for setup, 1 for status */ num_trbs = 2; /*

9 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] xhci: Fix control transfer error on Etron xHCI host" 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 5e1c67abc9301d05130b7e267c204e7005503b33 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024120247-spew-molasses-0b53@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5e1c67abc9301d05130b7e267c204e7005503b33 Mon Sep 17 00:00:00 2001 From: Kuangyi Chiang <ki.chiang65(a)gmail.com> Date: Wed, 6 Nov 2024 12:14:45 +0200 Subject: [PATCH] xhci: Fix control transfer error on Etron xHCI host Performing a stability stress test on a USB3.0 2.5G ethernet adapter results in errors like this: [ 91.441469] r8152 2-3:1.0 eth3: get_registers -71 [ 91.458659] r8152 2-3:1.0 eth3: get_registers -71 [ 91.475911] r8152 2-3:1.0 eth3: get_registers -71 [ 91.493203] r8152 2-3:1.0 eth3: get_registers -71 [ 91.510421] r8152 2-3:1.0 eth3: get_registers -71 The r8152 driver will periodically issue lots of control-IN requests to access the status of ethernet adapter hardware registers during the test. This happens when the xHCI driver enqueue a control TD (which cross over the Link TRB between two ring segments, as shown) in the endpoint zero's transfer ring. Seems the Etron xHCI host can not perform this TD correctly, causing the USB transfer error occurred, maybe the upper driver retry that control-IN request can solve problem, but not all drivers do this. | | ------- | TRB | Setup Stage ------- | TRB | Link ------- ------- | TRB | Data Stage ------- | TRB | Status Stage ------- | | To work around this, the xHCI driver should enqueue a No Op TRB if next available TRB is the Link TRB in the ring segment, this can prevent the Setup and Data Stage TRB to be breaked by the Link TRB. Check if the XHCI_ETRON_HOST quirk flag is set before invoking the workaround in xhci_queue_ctrl_tx(). Fixes: d0e96f5a71a0 ("USB: xhci: Control transfer support.") Cc: stable(a)vger.kernel.org Signed-off-by: Kuangyi Chiang <ki.chiang65(a)gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Link: https://lore.kernel.org/r/20241106101459.775897-20-mathias.nyman@linux.inte… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index f62b243d0fc4..517df97ef496 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -3733,6 +3733,20 @@ int xhci_queue_ctrl_tx(struct xhci_hcd *xhci, gfp_t mem_flags, if (!urb->setup_packet) return -EINVAL; + if ((xhci->quirks & XHCI_ETRON_HOST) && + urb->dev->speed >= USB_SPEED_SUPER) { + /* + * If next available TRB is the Link TRB in the ring segment then + * enqueue a No Op TRB, this can prevent the Setup and Data Stage + * TRB to be breaked by the Link TRB. + */ + if (trb_is_link(ep_ring->enqueue + 1)) { + field = TRB_TYPE(TRB_TR_NOOP) | ep_ring->cycle_state; + queue_trb(xhci, ep_ring, false, 0, 0, + TRB_INTR_TARGET(0), field); + } + } + /* 1 TRB for setup, 1 for status */ num_trbs = 2; /*

9 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] xhci: Fix control transfer error on Etron xHCI host" 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 5e1c67abc9301d05130b7e267c204e7005503b33 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024120246-volley-handbook-e11d@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5e1c67abc9301d05130b7e267c204e7005503b33 Mon Sep 17 00:00:00 2001 From: Kuangyi Chiang <ki.chiang65(a)gmail.com> Date: Wed, 6 Nov 2024 12:14:45 +0200 Subject: [PATCH] xhci: Fix control transfer error on Etron xHCI host Performing a stability stress test on a USB3.0 2.5G ethernet adapter results in errors like this: [ 91.441469] r8152 2-3:1.0 eth3: get_registers -71 [ 91.458659] r8152 2-3:1.0 eth3: get_registers -71 [ 91.475911] r8152 2-3:1.0 eth3: get_registers -71 [ 91.493203] r8152 2-3:1.0 eth3: get_registers -71 [ 91.510421] r8152 2-3:1.0 eth3: get_registers -71 The r8152 driver will periodically issue lots of control-IN requests to access the status of ethernet adapter hardware registers during the test. This happens when the xHCI driver enqueue a control TD (which cross over the Link TRB between two ring segments, as shown) in the endpoint zero's transfer ring. Seems the Etron xHCI host can not perform this TD correctly, causing the USB transfer error occurred, maybe the upper driver retry that control-IN request can solve problem, but not all drivers do this. | | ------- | TRB | Setup Stage ------- | TRB | Link ------- ------- | TRB | Data Stage ------- | TRB | Status Stage ------- | | To work around this, the xHCI driver should enqueue a No Op TRB if next available TRB is the Link TRB in the ring segment, this can prevent the Setup and Data Stage TRB to be breaked by the Link TRB. Check if the XHCI_ETRON_HOST quirk flag is set before invoking the workaround in xhci_queue_ctrl_tx(). Fixes: d0e96f5a71a0 ("USB: xhci: Control transfer support.") Cc: stable(a)vger.kernel.org Signed-off-by: Kuangyi Chiang <ki.chiang65(a)gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Link: https://lore.kernel.org/r/20241106101459.775897-20-mathias.nyman@linux.inte… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index f62b243d0fc4..517df97ef496 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -3733,6 +3733,20 @@ int xhci_queue_ctrl_tx(struct xhci_hcd *xhci, gfp_t mem_flags, if (!urb->setup_packet) return -EINVAL; + if ((xhci->quirks & XHCI_ETRON_HOST) && + urb->dev->speed >= USB_SPEED_SUPER) { + /* + * If next available TRB is the Link TRB in the ring segment then + * enqueue a No Op TRB, this can prevent the Setup and Data Stage + * TRB to be breaked by the Link TRB. + */ + if (trb_is_link(ep_ring->enqueue + 1)) { + field = TRB_TYPE(TRB_TR_NOOP) | ep_ring->cycle_state; + queue_trb(xhci, ep_ring, false, 0, 0, + TRB_INTR_TARGET(0), field); + } + } + /* 1 TRB for setup, 1 for status */ num_trbs = 2; /*

9 months, 2 weeks

1
0
0 0

FAILED: patch "[PATCH] xhci: Fix control transfer error on Etron xHCI host" 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 5e1c67abc9301d05130b7e267c204e7005503b33 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024120245-celestial-coherent-9ce2@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 5e1c67abc9301d05130b7e267c204e7005503b33 Mon Sep 17 00:00:00 2001 From: Kuangyi Chiang <ki.chiang65(a)gmail.com> Date: Wed, 6 Nov 2024 12:14:45 +0200 Subject: [PATCH] xhci: Fix control transfer error on Etron xHCI host Performing a stability stress test on a USB3.0 2.5G ethernet adapter results in errors like this: [ 91.441469] r8152 2-3:1.0 eth3: get_registers -71 [ 91.458659] r8152 2-3:1.0 eth3: get_registers -71 [ 91.475911] r8152 2-3:1.0 eth3: get_registers -71 [ 91.493203] r8152 2-3:1.0 eth3: get_registers -71 [ 91.510421] r8152 2-3:1.0 eth3: get_registers -71 The r8152 driver will periodically issue lots of control-IN requests to access the status of ethernet adapter hardware registers during the test. This happens when the xHCI driver enqueue a control TD (which cross over the Link TRB between two ring segments, as shown) in the endpoint zero's transfer ring. Seems the Etron xHCI host can not perform this TD correctly, causing the USB transfer error occurred, maybe the upper driver retry that control-IN request can solve problem, but not all drivers do this. | | ------- | TRB | Setup Stage ------- | TRB | Link ------- ------- | TRB | Data Stage ------- | TRB | Status Stage ------- | | To work around this, the xHCI driver should enqueue a No Op TRB if next available TRB is the Link TRB in the ring segment, this can prevent the Setup and Data Stage TRB to be breaked by the Link TRB. Check if the XHCI_ETRON_HOST quirk flag is set before invoking the workaround in xhci_queue_ctrl_tx(). Fixes: d0e96f5a71a0 ("USB: xhci: Control transfer support.") Cc: stable(a)vger.kernel.org Signed-off-by: Kuangyi Chiang <ki.chiang65(a)gmail.com> Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com> Link: https://lore.kernel.org/r/20241106101459.775897-20-mathias.nyman@linux.inte… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c index f62b243d0fc4..517df97ef496 100644 --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -3733,6 +3733,20 @@ int xhci_queue_ctrl_tx(struct xhci_hcd *xhci, gfp_t mem_flags, if (!urb->setup_packet) return -EINVAL; + if ((xhci->quirks & XHCI_ETRON_HOST) && + urb->dev->speed >= USB_SPEED_SUPER) { + /* + * If next available TRB is the Link TRB in the ring segment then + * enqueue a No Op TRB, this can prevent the Setup and Data Stage + * TRB to be breaked by the Link TRB. + */ + if (trb_is_link(ep_ring->enqueue + 1)) { + field = TRB_TYPE(TRB_TR_NOOP) | ep_ring->cycle_state; + queue_trb(xhci, ep_ring, false, 0, 0, + TRB_INTR_TARGET(0), field); + } + } + /* 1 TRB for setup, 1 for status */ num_trbs = 2; /*

9 months, 2 weeks

1
0
0 0

I/ITSEC Attendee's Contact List

by Jennifer Martin

Hi, I wanted to check if you’d be interested in acquiring the attendees list of I/ITSEC: The Interservice/Industry Training, Simulation & Education Conference 2024. Date: 02 - 05 Dec 2024 Location: Orlando, USA. Registrants Counts: 17,157+ visitors. Each contact contains: Contact Name, Job Title, Company Name, Company website, Physical Address, Phone Number, and Official Email address. Let me know if you are interested to see the pricing. Regards, Jennifer Martin Sr. Marketing Manager If you do not wish to receive this newsletter reply “Not interested”

9 months, 2 weeks

1
0
0 0

[PATCH] ALSA: usb-audio: Add extra PID for RME Digiface USB

by Asahi Lina

It seems there is an alternate version of the hardware with a different PID. User testing reveals this still works with the same interface as far as the kernel is concerned, so just add the extra PID. Thanks to Heiko Engemann for testing with this version. Due to the way quirks-table.h is structured, that means we have to turn the entire quirk struct into a macro to avoid duplicating it... Cc: stable(a)vger.kernel.org Signed-off-by: Asahi Lina <lina(a)asahilina.net> --- sound/usb/mixer_quirks.c | 1 + sound/usb/quirks-table.h | 341 ++++++++++++++++++++++++----------------------- sound/usb/quirks.c | 2 + 3 files changed, 176 insertions(+), 168 deletions(-) diff --git a/sound/usb/mixer_quirks.c b/sound/usb/mixer_quirks.c index 6456e87e2f397478aa1d767bc27f15d7b09acb86..a95ebcf4e46e76b19ec439c4ec02f18e650f96a3 100644 --- a/sound/usb/mixer_quirks.c +++ b/sound/usb/mixer_quirks.c @@ -4059,6 +4059,7 @@ int snd_usb_mixer_apply_create_quirk(struct usb_mixer_interface *mixer) err = snd_bbfpro_controls_create(mixer); break; case USB_ID(0x2a39, 0x3f8c): /* RME Digiface USB */ + case USB_ID(0x2a39, 0x3fa0): /* RME Digiface USB (alternate) */ err = snd_rme_digiface_controls_create(mixer); break; case USB_ID(0x2b73, 0x0017): /* Pioneer DJ DJM-250MK2 */ diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h index 199d0603cf8e592930199097a9fa009a7b5308d8..3f8beacca27a1787987ee7eba08456eb3598231c 100644 --- a/sound/usb/quirks-table.h +++ b/sound/usb/quirks-table.h @@ -3616,176 +3616,181 @@ YAMAHA_DEVICE(0x7010, "UB99"), } } }, -{ - /* Only claim interface 0 */ - .match_flags = USB_DEVICE_ID_MATCH_VENDOR | - USB_DEVICE_ID_MATCH_PRODUCT | - USB_DEVICE_ID_MATCH_INT_CLASS | - USB_DEVICE_ID_MATCH_INT_NUMBER, - .idVendor = 0x2a39, - .idProduct = 0x3f8c, - .bInterfaceClass = USB_CLASS_VENDOR_SPEC, - .bInterfaceNumber = 0, - QUIRK_DRIVER_INFO { - QUIRK_DATA_COMPOSITE { +#define QUIRK_RME_DIGIFACE(pid) \ +{ \ + /* Only claim interface 0 */ \ + .match_flags = USB_DEVICE_ID_MATCH_VENDOR | \ + USB_DEVICE_ID_MATCH_PRODUCT | \ + USB_DEVICE_ID_MATCH_INT_CLASS | \ + USB_DEVICE_ID_MATCH_INT_NUMBER, \ + .idVendor = 0x2a39, \ + .idProduct = pid, \ + .bInterfaceClass = USB_CLASS_VENDOR_SPEC, \ + .bInterfaceNumber = 0, \ + QUIRK_DRIVER_INFO { \ + QUIRK_DATA_COMPOSITE { \ /* * Three modes depending on sample rate band, * with different channel counts for in/out - */ - { QUIRK_DATA_STANDARD_MIXER(0) }, - { - QUIRK_DATA_AUDIOFORMAT(0) { - .formats = SNDRV_PCM_FMTBIT_S32_LE, - .channels = 34, // outputs - .fmt_bits = 24, - .iface = 0, - .altsetting = 1, - .altset_idx = 1, - .endpoint = 0x02, - .ep_idx = 1, - .ep_attr = USB_ENDPOINT_XFER_ISOC | - USB_ENDPOINT_SYNC_ASYNC, - .rates = SNDRV_PCM_RATE_32000 | - SNDRV_PCM_RATE_44100 | - SNDRV_PCM_RATE_48000, - .rate_min = 32000, - .rate_max = 48000, - .nr_rates = 3, - .rate_table = (unsigned int[]) { - 32000, 44100, 48000, - }, - .sync_ep = 0x81, - .sync_iface = 0, - .sync_altsetting = 1, - .sync_ep_idx = 0, - .implicit_fb = 1, - }, - }, - { - QUIRK_DATA_AUDIOFORMAT(0) { - .formats = SNDRV_PCM_FMTBIT_S32_LE, - .channels = 18, // outputs - .fmt_bits = 24, - .iface = 0, - .altsetting = 1, - .altset_idx = 1, - .endpoint = 0x02, - .ep_idx = 1, - .ep_attr = USB_ENDPOINT_XFER_ISOC | - USB_ENDPOINT_SYNC_ASYNC, - .rates = SNDRV_PCM_RATE_64000 | - SNDRV_PCM_RATE_88200 | - SNDRV_PCM_RATE_96000, - .rate_min = 64000, - .rate_max = 96000, - .nr_rates = 3, - .rate_table = (unsigned int[]) { - 64000, 88200, 96000, - }, - .sync_ep = 0x81, - .sync_iface = 0, - .sync_altsetting = 1, - .sync_ep_idx = 0, - .implicit_fb = 1, - }, - }, - { - QUIRK_DATA_AUDIOFORMAT(0) { - .formats = SNDRV_PCM_FMTBIT_S32_LE, - .channels = 10, // outputs - .fmt_bits = 24, - .iface = 0, - .altsetting = 1, - .altset_idx = 1, - .endpoint = 0x02, - .ep_idx = 1, - .ep_attr = USB_ENDPOINT_XFER_ISOC | - USB_ENDPOINT_SYNC_ASYNC, - .rates = SNDRV_PCM_RATE_KNOT | - SNDRV_PCM_RATE_176400 | - SNDRV_PCM_RATE_192000, - .rate_min = 128000, - .rate_max = 192000, - .nr_rates = 3, - .rate_table = (unsigned int[]) { - 128000, 176400, 192000, - }, - .sync_ep = 0x81, - .sync_iface = 0, - .sync_altsetting = 1, - .sync_ep_idx = 0, - .implicit_fb = 1, - }, - }, - { - QUIRK_DATA_AUDIOFORMAT(0) { - .formats = SNDRV_PCM_FMTBIT_S32_LE, - .channels = 32, // inputs - .fmt_bits = 24, - .iface = 0, - .altsetting = 1, - .altset_idx = 1, - .endpoint = 0x81, - .ep_attr = USB_ENDPOINT_XFER_ISOC | - USB_ENDPOINT_SYNC_ASYNC, - .rates = SNDRV_PCM_RATE_32000 | - SNDRV_PCM_RATE_44100 | - SNDRV_PCM_RATE_48000, - .rate_min = 32000, - .rate_max = 48000, - .nr_rates = 3, - .rate_table = (unsigned int[]) { - 32000, 44100, 48000, - } - } - }, - { - QUIRK_DATA_AUDIOFORMAT(0) { - .formats = SNDRV_PCM_FMTBIT_S32_LE, - .channels = 16, // inputs - .fmt_bits = 24, - .iface = 0, - .altsetting = 1, - .altset_idx = 1, - .endpoint = 0x81, - .ep_attr = USB_ENDPOINT_XFER_ISOC | - USB_ENDPOINT_SYNC_ASYNC, - .rates = SNDRV_PCM_RATE_64000 | - SNDRV_PCM_RATE_88200 | - SNDRV_PCM_RATE_96000, - .rate_min = 64000, - .rate_max = 96000, - .nr_rates = 3, - .rate_table = (unsigned int[]) { - 64000, 88200, 96000, - } - } - }, - { - QUIRK_DATA_AUDIOFORMAT(0) { - .formats = SNDRV_PCM_FMTBIT_S32_LE, - .channels = 8, // inputs - .fmt_bits = 24, - .iface = 0, - .altsetting = 1, - .altset_idx = 1, - .endpoint = 0x81, - .ep_attr = USB_ENDPOINT_XFER_ISOC | - USB_ENDPOINT_SYNC_ASYNC, - .rates = SNDRV_PCM_RATE_KNOT | - SNDRV_PCM_RATE_176400 | - SNDRV_PCM_RATE_192000, - .rate_min = 128000, - .rate_max = 192000, - .nr_rates = 3, - .rate_table = (unsigned int[]) { - 128000, 176400, 192000, - } - } - }, - QUIRK_COMPOSITE_END - } - } -}, + */ \ + { QUIRK_DATA_STANDARD_MIXER(0) }, \ + { \ + QUIRK_DATA_AUDIOFORMAT(0) { \ + .formats = SNDRV_PCM_FMTBIT_S32_LE, \ + .channels = 34, /* outputs */ \ + .fmt_bits = 24, \ + .iface = 0, \ + .altsetting = 1, \ + .altset_idx = 1, \ + .endpoint = 0x02, \ + .ep_idx = 1, \ + .ep_attr = USB_ENDPOINT_XFER_ISOC | \ + USB_ENDPOINT_SYNC_ASYNC, \ + .rates = SNDRV_PCM_RATE_32000 | \ + SNDRV_PCM_RATE_44100 | \ + SNDRV_PCM_RATE_48000, \ + .rate_min = 32000, \ + .rate_max = 48000, \ + .nr_rates = 3, \ + .rate_table = (unsigned int[]) { \ + 32000, 44100, 48000, \ + }, \ + .sync_ep = 0x81, \ + .sync_iface = 0, \ + .sync_altsetting = 1, \ + .sync_ep_idx = 0, \ + .implicit_fb = 1, \ + }, \ + }, \ + { \ + QUIRK_DATA_AUDIOFORMAT(0) { \ + .formats = SNDRV_PCM_FMTBIT_S32_LE, \ + .channels = 18, /* outputs */ \ + .fmt_bits = 24, \ + .iface = 0, \ + .altsetting = 1, \ + .altset_idx = 1, \ + .endpoint = 0x02, \ + .ep_idx = 1, \ + .ep_attr = USB_ENDPOINT_XFER_ISOC | \ + USB_ENDPOINT_SYNC_ASYNC, \ + .rates = SNDRV_PCM_RATE_64000 | \ + SNDRV_PCM_RATE_88200 | \ + SNDRV_PCM_RATE_96000, \ + .rate_min = 64000, \ + .rate_max = 96000, \ + .nr_rates = 3, \ + .rate_table = (unsigned int[]) { \ + 64000, 88200, 96000, \ + }, \ + .sync_ep = 0x81, \ + .sync_iface = 0, \ + .sync_altsetting = 1, \ + .sync_ep_idx = 0, \ + .implicit_fb = 1, \ + }, \ + }, \ + { \ + QUIRK_DATA_AUDIOFORMAT(0) { \ + .formats = SNDRV_PCM_FMTBIT_S32_LE, \ + .channels = 10, /* outputs */ \ + .fmt_bits = 24, \ + .iface = 0, \ + .altsetting = 1, \ + .altset_idx = 1, \ + .endpoint = 0x02, \ + .ep_idx = 1, \ + .ep_attr = USB_ENDPOINT_XFER_ISOC | \ + USB_ENDPOINT_SYNC_ASYNC, \ + .rates = SNDRV_PCM_RATE_KNOT | \ + SNDRV_PCM_RATE_176400 | \ + SNDRV_PCM_RATE_192000, \ + .rate_min = 128000, \ + .rate_max = 192000, \ + .nr_rates = 3, \ + .rate_table = (unsigned int[]) { \ + 128000, 176400, 192000, \ + }, \ + .sync_ep = 0x81, \ + .sync_iface = 0, \ + .sync_altsetting = 1, \ + .sync_ep_idx = 0, \ + .implicit_fb = 1, \ + }, \ + }, \ + { \ + QUIRK_DATA_AUDIOFORMAT(0) { \ + .formats = SNDRV_PCM_FMTBIT_S32_LE, \ + .channels = 32, /* inputs */ \ + .fmt_bits = 24, \ + .iface = 0, \ + .altsetting = 1, \ + .altset_idx = 1, \ + .endpoint = 0x81, \ + .ep_attr = USB_ENDPOINT_XFER_ISOC | \ + USB_ENDPOINT_SYNC_ASYNC, \ + .rates = SNDRV_PCM_RATE_32000 | \ + SNDRV_PCM_RATE_44100 | \ + SNDRV_PCM_RATE_48000, \ + .rate_min = 32000, \ + .rate_max = 48000, \ + .nr_rates = 3, \ + .rate_table = (unsigned int[]) { \ + 32000, 44100, 48000, \ + } \ + } \ + }, \ + { \ + QUIRK_DATA_AUDIOFORMAT(0) { \ + .formats = SNDRV_PCM_FMTBIT_S32_LE, \ + .channels = 16, /* inputs */ \ + .fmt_bits = 24, \ + .iface = 0, \ + .altsetting = 1, \ + .altset_idx = 1, \ + .endpoint = 0x81, \ + .ep_attr = USB_ENDPOINT_XFER_ISOC | \ + USB_ENDPOINT_SYNC_ASYNC, \ + .rates = SNDRV_PCM_RATE_64000 | \ + SNDRV_PCM_RATE_88200 | \ + SNDRV_PCM_RATE_96000, \ + .rate_min = 64000, \ + .rate_max = 96000, \ + .nr_rates = 3, \ + .rate_table = (unsigned int[]) { \ + 64000, 88200, 96000, \ + } \ + } \ + }, \ + { \ + QUIRK_DATA_AUDIOFORMAT(0) { \ + .formats = SNDRV_PCM_FMTBIT_S32_LE, \ + .channels = 8, /* inputs */ \ + .fmt_bits = 24, \ + .iface = 0, \ + .altsetting = 1, \ + .altset_idx = 1, \ + .endpoint = 0x81, \ + .ep_attr = USB_ENDPOINT_XFER_ISOC | \ + USB_ENDPOINT_SYNC_ASYNC, \ + .rates = SNDRV_PCM_RATE_KNOT | \ + SNDRV_PCM_RATE_176400 | \ + SNDRV_PCM_RATE_192000, \ + .rate_min = 128000, \ + .rate_max = 192000, \ + .nr_rates = 3, \ + .rate_table = (unsigned int[]) { \ + 128000, 176400, 192000, \ + } \ + } \ + }, \ + QUIRK_COMPOSITE_END \ + } \ + } \ +} + +QUIRK_RME_DIGIFACE(0x3f8c), +QUIRK_RME_DIGIFACE(0x3fa0), + #undef USB_DEVICE_VENDOR_SPEC #undef USB_AUDIO_DEVICE diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c index c5fd180357d1e8cc4560bf03ae1ab3c12e6ee9d1..9f38288a1bede8a360abbd0296f571cdf9a72c7d 100644 --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -1638,6 +1638,7 @@ int snd_usb_apply_boot_quirk(struct usb_device *dev, return snd_usb_motu_microbookii_boot_quirk(dev); break; case USB_ID(0x2a39, 0x3f8c): /* RME Digiface USB */ + case USB_ID(0x2a39, 0x3fa0): /* RME Digiface USB (alternate) */ return snd_usb_rme_digiface_boot_quirk(dev); } @@ -1851,6 +1852,7 @@ void snd_usb_set_format_quirk(struct snd_usb_substream *subs, mbox3_set_format_quirk(subs, fmt); /* Digidesign Mbox 3 */ break; case USB_ID(0x2a39, 0x3f8c): /* RME Digiface USB */ + case USB_ID(0x2a39, 0x3fa0): /* RME Digiface USB (alternate) */ rme_digiface_set_format_quirk(subs); break; } --- base-commit: adc218676eef25575469234709c2d87185ca223a change-id: 20241202-rme-digiface-usb-id-df05cf818653 Cheers, ~~ Lina

9 months, 2 weeks

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror December 2024