Signed-off-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
- fs/filesystems.c | 14 +++++++++-----
+ fs/filesystems.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
-diff --git a/fs/filesystems.c b/fs/filesystems.c
-index 5e1a190133738..148073e372acd 100644
--- a/fs/filesystems.c
+++ b/fs/filesystems.c
-@@ -155,15 +155,19 @@ static int fs_index(const char __user * __name)
+@@ -155,15 +155,19 @@ static int fs_index(const char __user *
static int fs_name(unsigned int index, char __user * buf)
{
struct file_system_type * tmp;
/* OK, we got the reference, so we can safely block */
len = strlen(tmp->name) + 1;
---
-2.39.5
-
drm-amd-display-do-not-add-mhard-float-to-dcn2-1-0-_resource.o-for-clang.patch
net-mdiobus-fix-potential-out-of-bounds-read-write-a.patch
fs-filesystems-fix-potential-unsigned-integer-underf.patch
+usb-flush-altsetting-0-endpoints-before-reinitializating-them-after-reset.patch
+xen-arm-call-uaccess_ttbr0_enable-for-dm_op-hypercall.patch
--- /dev/null
+From 89bb3dc13ac29a563f4e4c555e422882f64742bd Mon Sep 17 00:00:00 2001
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+Date: Wed, 14 May 2025 16:25:20 +0300
+Subject: usb: Flush altsetting 0 endpoints before reinitializating them after reset.
+
+From: Mathias Nyman <mathias.nyman@linux.intel.com>
+
+commit 89bb3dc13ac29a563f4e4c555e422882f64742bd upstream.
+
+usb core avoids sending a Set-Interface altsetting 0 request after device
+reset, and instead relies on calling usb_disable_interface() and
+usb_enable_interface() to flush and reset host-side of those endpoints.
+
+xHCI hosts allocate and set up endpoint ring buffers and host_ep->hcpriv
+during usb_hcd_alloc_bandwidth() callback, which in this case is called
+before flushing the endpoint in usb_disable_interface().
+
+Call usb_disable_interface() before usb_hcd_alloc_bandwidth() to ensure
+URBs are flushed before new ring buffers for the endpoints are allocated.
+
+Otherwise host driver will attempt to find and remove old stale URBs
+from a freshly allocated new ringbuffer.
+
+Cc: stable <stable@kernel.org>
+Fixes: 4fe0387afa89 ("USB: don't send Set-Interface after reset")
+Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
+Link: https://lore.kernel.org/r/20250514132520.225345-1-mathias.nyman@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/usb/core/hub.c | 16 ++++++++++++++--
+ 1 file changed, 14 insertions(+), 2 deletions(-)
+
+--- a/drivers/usb/core/hub.c
++++ b/drivers/usb/core/hub.c
+@@ -5826,6 +5826,7 @@ static int usb_reset_and_verify_device(s
+ struct usb_hub *parent_hub;
+ struct usb_hcd *hcd = bus_to_hcd(udev->bus);
+ struct usb_device_descriptor descriptor = udev->descriptor;
++ struct usb_interface *intf;
+ struct usb_host_bos *bos;
+ int i, j, ret = 0;
+ int port1 = udev->portnum;
+@@ -5887,6 +5888,18 @@ static int usb_reset_and_verify_device(s
+ if (!udev->actconfig)
+ goto done;
+
++ /*
++ * Some devices can't handle setting default altsetting 0 with a
++ * Set-Interface request. Disable host-side endpoints of those
++ * interfaces here. Enable and reset them back after host has set
++ * its internal endpoint structures during usb_hcd_alloc_bandwith()
++ */
++ for (i = 0; i < udev->actconfig->desc.bNumInterfaces; i++) {
++ intf = udev->actconfig->interface[i];
++ if (intf->cur_altsetting->desc.bAlternateSetting == 0)
++ usb_disable_interface(udev, intf, true);
++ }
++
+ mutex_lock(hcd->bandwidth_mutex);
+ ret = usb_hcd_alloc_bandwidth(udev, udev->actconfig, NULL, NULL);
+ if (ret < 0) {
+@@ -5918,12 +5931,11 @@ static int usb_reset_and_verify_device(s
+ */
+ for (i = 0; i < udev->actconfig->desc.bNumInterfaces; i++) {
+ struct usb_host_config *config = udev->actconfig;
+- struct usb_interface *intf = config->interface[i];
+ struct usb_interface_descriptor *desc;
+
++ intf = config->interface[i];
+ desc = &intf->cur_altsetting->desc;
+ if (desc->bAlternateSetting == 0) {
+- usb_disable_interface(udev, intf, true);
+ usb_enable_interface(udev, intf, true);
+ ret = 0;
+ } else {
--- /dev/null
+From 7f9bbc1140ff8796230bc2634055763e271fd692 Mon Sep 17 00:00:00 2001
+From: Stefano Stabellini <stefano.stabellini@amd.com>
+Date: Mon, 12 May 2025 14:54:52 -0700
+Subject: xen/arm: call uaccess_ttbr0_enable for dm_op hypercall
+
+From: Stefano Stabellini <stefano.stabellini@amd.com>
+
+commit 7f9bbc1140ff8796230bc2634055763e271fd692 upstream.
+
+dm_op hypercalls might come from userspace and pass memory addresses as
+parameters. The memory addresses typically correspond to buffers
+allocated in userspace to hold extra hypercall parameters.
+
+On ARM, when CONFIG_ARM64_SW_TTBR0_PAN is enabled, they might not be
+accessible by Xen, as a result ioreq hypercalls might fail. See the
+existing comment in arch/arm64/xen/hypercall.S regarding privcmd_call
+for reference.
+
+For privcmd_call, Linux calls uaccess_ttbr0_enable before issuing the
+hypercall thanks to commit 9cf09d68b89a. We need to do the same for
+dm_op. This resolves the problem.
+
+Cc: stable@kernel.org
+Fixes: 9cf09d68b89a ("arm64: xen: Enable user access before a privcmd hvc call")
+Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>
+Reviewed-by: Juergen Gross <jgross@suse.com>
+Message-ID: <alpine.DEB.2.22.394.2505121446370.8380@ubuntu-linux-20-04-desktop>
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/xen/hypercall.S | 21 ++++++++++++++++++++-
+ 1 file changed, 20 insertions(+), 1 deletion(-)
+
+--- a/arch/arm64/xen/hypercall.S
++++ b/arch/arm64/xen/hypercall.S
+@@ -84,7 +84,26 @@ HYPERCALL1(tmem_op);
+ HYPERCALL1(platform_op_raw);
+ HYPERCALL2(multicall);
+ HYPERCALL2(vm_assist);
+-HYPERCALL3(dm_op);
++
++SYM_FUNC_START(HYPERVISOR_dm_op)
++ mov x16, #__HYPERVISOR_dm_op; \
++ /*
++ * dm_op hypercalls are issued by the userspace. The kernel needs to
++ * enable access to TTBR0_EL1 as the hypervisor would issue stage 1
++ * translations to user memory via AT instructions. Since AT
++ * instructions are not affected by the PAN bit (ARMv8.1), we only
++ * need the explicit uaccess_enable/disable if the TTBR0 PAN emulation
++ * is enabled (it implies that hardware UAO and PAN disabled).
++ */
++ uaccess_ttbr0_enable x6, x7, x8
++ hvc XEN_IMM
++
++ /*
++ * Disable userspace access from kernel once the hyp call completed.
++ */
++ uaccess_ttbr0_disable x6, x7
++ ret
++SYM_FUNC_END(HYPERVISOR_dm_op);
+
+ ENTRY(privcmd_call)
+ mov x16, x0