From: Greg Kroah-Hartman Date: Mon, 17 Apr 2023 08:05:51 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v4.14.313~30 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=abdbe2b00ccaeb6684a9806d4de5ea626f7bcc2a;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: cgroup-cpuset-wake-up-cpuset_attach_wq-tasks-in-cpuset_cancel_attach.patch scsi-ses-handle-enclosure-with-just-a-primary-component-gracefully.patch x86-pci-add-quirk-for-amd-xhci-controller-that-loses-msi-x-state-in-d3hot.patch --- diff --git a/queue-5.10/cgroup-cpuset-wake-up-cpuset_attach_wq-tasks-in-cpuset_cancel_attach.patch b/queue-5.10/cgroup-cpuset-wake-up-cpuset_attach_wq-tasks-in-cpuset_cancel_attach.patch new file mode 100644 index 00000000000..f3f90fa4897 --- /dev/null +++ b/queue-5.10/cgroup-cpuset-wake-up-cpuset_attach_wq-tasks-in-cpuset_cancel_attach.patch @@ -0,0 +1,49 @@ +From ba9182a89626d5f83c2ee4594f55cb9c1e60f0e2 Mon Sep 17 00:00:00 2001 +From: Waiman Long +Date: Tue, 11 Apr 2023 09:35:57 -0400 +Subject: cgroup/cpuset: Wake up cpuset_attach_wq tasks in cpuset_cancel_attach() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Waiman Long + +commit ba9182a89626d5f83c2ee4594f55cb9c1e60f0e2 upstream. + +After a successful cpuset_can_attach() call which increments the +attach_in_progress flag, either cpuset_cancel_attach() or cpuset_attach() +will be called later. In cpuset_attach(), tasks in cpuset_attach_wq, +if present, will be woken up at the end. That is not the case in +cpuset_cancel_attach(). So missed wakeup is possible if the attach +operation is somehow cancelled. Fix that by doing the wakeup in +cpuset_cancel_attach() as well. + +Fixes: e44193d39e8d ("cpuset: let hotplug propagation work wait for task attaching") +Signed-off-by: Waiman Long +Reviewed-by: Michal Koutný +Cc: stable@vger.kernel.org # v3.11+ +Signed-off-by: Tejun Heo +Signed-off-by: Greg Kroah-Hartman +--- + kernel/cgroup/cpuset.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/kernel/cgroup/cpuset.c ++++ b/kernel/cgroup/cpuset.c +@@ -2188,11 +2188,15 @@ out_unlock: + static void cpuset_cancel_attach(struct cgroup_taskset *tset) + { + struct cgroup_subsys_state *css; ++ struct cpuset *cs; + + cgroup_taskset_first(tset, &css); ++ cs = css_cs(css); + + percpu_down_write(&cpuset_rwsem); +- css_cs(css)->attach_in_progress--; ++ cs->attach_in_progress--; ++ if (!cs->attach_in_progress) ++ wake_up(&cpuset_attach_wq); + percpu_up_write(&cpuset_rwsem); + } + diff --git a/queue-5.10/scsi-ses-handle-enclosure-with-just-a-primary-component-gracefully.patch b/queue-5.10/scsi-ses-handle-enclosure-with-just-a-primary-component-gracefully.patch new file mode 100644 index 00000000000..0e482245eca --- /dev/null +++ b/queue-5.10/scsi-ses-handle-enclosure-with-just-a-primary-component-gracefully.patch @@ -0,0 +1,141 @@ +From c8e22b7a1694bb8d025ea636816472739d859145 Mon Sep 17 00:00:00 2001 +From: Jiri Kosina +Date: Tue, 4 Apr 2023 21:23:42 +0200 +Subject: scsi: ses: Handle enclosure with just a primary component gracefully + +From: Jiri Kosina + +commit c8e22b7a1694bb8d025ea636816472739d859145 upstream. + +This reverts commit 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure +has no components") and introduces proper handling of case where there are +no detected secondary components, but primary component (enumerated in +num_enclosures) does exist. That fix was originally proposed by Ding Hui +. + +Completely ignoring devices that have one primary enclosure and no +secondary one results in ses_intf_add() bailing completely + + scsi 2:0:0:254: enclosure has no enumerated components + scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations such + +even on valid configurations with 1 primary and 0 secondary enclosures as +below: + + # sg_ses /dev/sg0 + 3PARdata SES 3321 + Supported diagnostic pages: + Supported Diagnostic Pages [sdp] [0x0] + Configuration (SES) [cf] [0x1] + Short Enclosure Status (SES) [ses] [0x8] + # sg_ses -p cf /dev/sg0 + 3PARdata SES 3321 + Configuration diagnostic page: + number of secondary subenclosures: 0 + generation code: 0x0 + enclosure descriptor list + Subenclosure identifier: 0 [primary] + relative ES process id: 0, number of ES processes: 1 + number of type descriptor headers: 1 + enclosure logical identifier (hex): 20000002ac02068d + enclosure vendor: 3PARdata product: VV rev: 3321 + type descriptor header and text list + Element type: Unspecified, subenclosure id: 0 + number of possible elements: 1 + +The changelog for the original fix follows + +===== +We can get a crash when disconnecting the iSCSI session, +the call trace like this: + + [ffff00002a00fb70] kfree at ffff00000830e224 + [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4 + [ffff00002a00fbd0] device_del at ffff0000086b6a98 + [ffff00002a00fc50] device_unregister at ffff0000086b6d58 + [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c + [ffff00002a00fca0] scsi_remove_device at ffff000008706134 + [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4 + [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0 + [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4 + [ffff00002a00fdb0] process_one_work at ffff00000810f35c + [ffff00002a00fe00] worker_thread at ffff00000810f648 + [ffff00002a00fe70] kthread at ffff000008116e98 + +In ses_intf_add, components count could be 0, and kcalloc 0 size scomp, +but not saved in edev->component[i].scratch + +In this situation, edev->component[0].scratch is an invalid pointer, +when kfree it in ses_intf_remove_enclosure, a crash like above would happen +The call trace also could be other random cases when kfree cannot catch +the invalid pointer + +We should not use edev->component[] array when the components count is 0 +We also need check index when use edev->component[] array in +ses_enclosure_data_process +===== + +Reported-by: Michal Kolar +Originally-by: Ding Hui +Cc: stable@vger.kernel.org +Fixes: 3fe97ff3d949 ("scsi: ses: Don't attach if enclosure has no components") +Signed-off-by: Jiri Kosina +Link: https://lore.kernel.org/r/nycvar.YFH.7.76.2304042122270.29760@cbobk.fhfr.pm +Tested-by: Michal Kolar +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman +--- + drivers/scsi/ses.c | 20 ++++++++------------ + 1 file changed, 8 insertions(+), 12 deletions(-) + +--- a/drivers/scsi/ses.c ++++ b/drivers/scsi/ses.c +@@ -503,9 +503,6 @@ static int ses_enclosure_find_by_addr(st + int i; + struct ses_component *scomp; + +- if (!edev->component[0].scratch) +- return 0; +- + for (i = 0; i < edev->components; i++) { + scomp = edev->component[i].scratch; + if (scomp->addr != efd->addr) +@@ -596,8 +593,10 @@ static void ses_enclosure_data_process(s + components++, + type_ptr[0], + name); +- else ++ else if (components < edev->components) + ecomp = &edev->component[components++]; ++ else ++ ecomp = ERR_PTR(-EINVAL); + + if (!IS_ERR(ecomp)) { + if (addl_desc_ptr) { +@@ -728,11 +727,6 @@ static int ses_intf_add(struct device *c + components += type_ptr[1]; + } + +- if (components == 0) { +- sdev_printk(KERN_WARNING, sdev, "enclosure has no enumerated components\n"); +- goto err_free; +- } +- + ses_dev->page1 = buf; + ses_dev->page1_len = len; + buf = NULL; +@@ -774,9 +768,11 @@ static int ses_intf_add(struct device *c + buf = NULL; + } + page2_not_supported: +- scomp = kcalloc(components, sizeof(struct ses_component), GFP_KERNEL); +- if (!scomp) +- goto err_free; ++ if (components > 0) { ++ scomp = kcalloc(components, sizeof(struct ses_component), GFP_KERNEL); ++ if (!scomp) ++ goto err_free; ++ } + + edev = enclosure_register(cdev->parent, dev_name(&sdev->sdev_gendev), + components, &ses_enclosure_callbacks); diff --git a/queue-5.10/series b/queue-5.10/series index 3addc46a845..e3bcbf83bb0 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -92,3 +92,6 @@ verify_pefile-relax-wrapper-length-check.patch asymmetric_keys-log-on-fatal-failures-in-pe-pkcs7.patch riscv-add-icache-flush-for-nommu-sigreturn-trampoline.patch net-sfp-initialize-sfp-i2c_block_size-at-sfp-allocation.patch +scsi-ses-handle-enclosure-with-just-a-primary-component-gracefully.patch +x86-pci-add-quirk-for-amd-xhci-controller-that-loses-msi-x-state-in-d3hot.patch +cgroup-cpuset-wake-up-cpuset_attach_wq-tasks-in-cpuset_cancel_attach.patch diff --git a/queue-5.10/x86-pci-add-quirk-for-amd-xhci-controller-that-loses-msi-x-state-in-d3hot.patch b/queue-5.10/x86-pci-add-quirk-for-amd-xhci-controller-that-loses-msi-x-state-in-d3hot.patch new file mode 100644 index 00000000000..0b979ebb992 --- /dev/null +++ b/queue-5.10/x86-pci-add-quirk-for-amd-xhci-controller-that-loses-msi-x-state-in-d3hot.patch @@ -0,0 +1,65 @@ +From f195fc1e9715ba826c3b62d58038f760f66a4fe9 Mon Sep 17 00:00:00 2001 +From: Basavaraj Natikar +Date: Wed, 29 Mar 2023 22:58:59 +0530 +Subject: x86/PCI: Add quirk for AMD XHCI controller that loses MSI-X state in D3hot + +From: Basavaraj Natikar + +commit f195fc1e9715ba826c3b62d58038f760f66a4fe9 upstream. + +The AMD [1022:15b8] USB controller loses some internal functional MSI-X +context when transitioning from D0 to D3hot. BIOS normally traps D0->D3hot +and D3hot->D0 transitions so it can save and restore that internal context, +but some firmware in the field can't do this because it fails to clear the +AMD_15B8_RCC_DEV2_EPF0_STRAP2 NO_SOFT_RESET bit. + +Clear AMD_15B8_RCC_DEV2_EPF0_STRAP2 NO_SOFT_RESET bit before USB controller +initialization during boot. + +Link: https://lore.kernel.org/linux-usb/Y%2Fz9GdHjPyF2rNG3@glanzmann.de/T/#u +Link: https://lore.kernel.org/r/20230329172859.699743-1-Basavaraj.Natikar@amd.com +Reported-by: Thomas Glanzmann +Tested-by: Thomas Glanzmann +Signed-off-by: Basavaraj Natikar +Signed-off-by: Bjorn Helgaas +Reviewed-by: Mario Limonciello +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/pci/fixup.c | 21 +++++++++++++++++++++ + 1 file changed, 21 insertions(+) + +--- a/arch/x86/pci/fixup.c ++++ b/arch/x86/pci/fixup.c +@@ -7,6 +7,7 @@ + #include + #include + #include ++#include + #include + #include + +@@ -824,3 +825,23 @@ static void rs690_fix_64bit_dma(struct p + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x7910, rs690_fix_64bit_dma); + + #endif ++ ++#ifdef CONFIG_AMD_NB ++ ++#define AMD_15B8_RCC_DEV2_EPF0_STRAP2 0x10136008 ++#define AMD_15B8_RCC_DEV2_EPF0_STRAP2_NO_SOFT_RESET_DEV2_F0_MASK 0x00000080L ++ ++static void quirk_clear_strap_no_soft_reset_dev2_f0(struct pci_dev *dev) ++{ ++ u32 data; ++ ++ if (!amd_smn_read(0, AMD_15B8_RCC_DEV2_EPF0_STRAP2, &data)) { ++ data &= ~AMD_15B8_RCC_DEV2_EPF0_STRAP2_NO_SOFT_RESET_DEV2_F0_MASK; ++ if (amd_smn_write(0, AMD_15B8_RCC_DEV2_EPF0_STRAP2, data)) ++ pci_err(dev, "Failed to write data 0x%x\n", data); ++ } else { ++ pci_err(dev, "Failed to read data\n"); ++ } ++} ++DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_AMD, 0x15b8, quirk_clear_strap_no_soft_reset_dev2_f0); ++#endif