From: Greg Kroah-Hartman Date: Sun, 28 Jun 2020 15:57:38 +0000 (+0200) Subject: 4.19-stable patches X-Git-Tag: v5.7.7~46 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=bcb3b8ba2e06307e9f51ac2688fb60d5aba89e52;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: cdc-acm-add-disable_echo-quirk-for-microchip-smsc-chip.patch scsi-zfcp-fix-panic-on-erp-timeout-for-previously-dismissed-erp-action.patch xhci-fix-enumeration-issue-when-setting-max-packet-size-for-fs-devices.patch xhci-fix-incorrect-ep_state_mask.patch xhci-return-if-xhci-doesn-t-support-lpm.patch --- diff --git a/queue-4.19/cdc-acm-add-disable_echo-quirk-for-microchip-smsc-chip.patch b/queue-4.19/cdc-acm-add-disable_echo-quirk-for-microchip-smsc-chip.patch new file mode 100644 index 00000000000..1f1d12f3341 --- /dev/null +++ b/queue-4.19/cdc-acm-add-disable_echo-quirk-for-microchip-smsc-chip.patch @@ -0,0 +1,34 @@ +From 03894573f2913181ee5aae0089f333b2131f2d4b Mon Sep 17 00:00:00 2001 +From: Joakim Tjernlund +Date: Fri, 5 Jun 2020 12:54:18 +0200 +Subject: cdc-acm: Add DISABLE_ECHO quirk for Microchip/SMSC chip + +From: Joakim Tjernlund + +commit 03894573f2913181ee5aae0089f333b2131f2d4b upstream. + +USB_DEVICE(0x0424, 0x274e) can send data before cdc_acm is ready, +causing garbage chars on the TTY causing stray input to the shell +and/or login prompt. + +Signed-off-by: Joakim Tjernlund +Cc: stable@vger.kernel.org +Acked-by: Oliver Neukum +Link: https://lore.kernel.org/r/20200605105418.22263-1-joakim.tjernlund@infinera.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/class/cdc-acm.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/usb/class/cdc-acm.c ++++ b/drivers/usb/class/cdc-acm.c +@@ -1721,6 +1721,8 @@ static int acm_pre_reset(struct usb_inte + + static const struct usb_device_id acm_ids[] = { + /* quirky and broken devices */ ++ { USB_DEVICE(0x0424, 0x274e), /* Microchip Technology, Inc. (formerly SMSC) */ ++ .driver_info = DISABLE_ECHO, }, /* DISABLE ECHO in termios flag */ + { USB_DEVICE(0x076d, 0x0006), /* Denso Cradle CU-321 */ + .driver_info = NO_UNION_NORMAL, },/* has no union descriptor */ + { USB_DEVICE(0x17ef, 0x7000), /* Lenovo USB modem */ diff --git a/queue-4.19/scsi-zfcp-fix-panic-on-erp-timeout-for-previously-dismissed-erp-action.patch b/queue-4.19/scsi-zfcp-fix-panic-on-erp-timeout-for-previously-dismissed-erp-action.patch new file mode 100644 index 00000000000..f09aac05100 --- /dev/null +++ b/queue-4.19/scsi-zfcp-fix-panic-on-erp-timeout-for-previously-dismissed-erp-action.patch @@ -0,0 +1,129 @@ +From 936e6b85da0476dd2edac7c51c68072da9fb4ba2 Mon Sep 17 00:00:00 2001 +From: Steffen Maier +Date: Tue, 23 Jun 2020 16:02:42 +0200 +Subject: scsi: zfcp: Fix panic on ERP timeout for previously dismissed ERP action + +From: Steffen Maier + +commit 936e6b85da0476dd2edac7c51c68072da9fb4ba2 upstream. + +Suppose that, for unrelated reasons, FSF requests on behalf of recovery are +very slow and can run into the ERP timeout. + +In the case at hand, we did adapter recovery to a large degree. However +due to the slowness a LUN open is pending so the corresponding fc_rport +remains blocked. After fast_io_fail_tmo we trigger close physical port +recovery for the port under which the LUN should have been opened. The new +higher order port recovery dismisses the pending LUN open ERP action and +dismisses the pending LUN open FSF request. Such dismissal decouples the +ERP action from the pending corresponding FSF request by setting +zfcp_fsf_req->erp_action to NULL (among other things) +[zfcp_erp_strategy_check_fsfreq()]. + +If now the ERP timeout for the pending open LUN request runs out, we must +not use zfcp_fsf_req->erp_action in the ERP timeout handler. This is a +problem since v4.15 commit 75492a51568b ("s390/scsi: Convert timers to use +timer_setup()"). Before that we intentionally only passed zfcp_erp_action +as context argument to zfcp_erp_timeout_handler(). + +Note: The lifetime of the corresponding zfcp_fsf_req object continues until +a (late) response or an (unrelated) adapter recovery. + +Just like the regular response path ignores dismissed requests +[zfcp_fsf_req_complete() => zfcp_fsf_protstatus_eval() => return early] the +ERP timeout handler now needs to ignore dismissed requests. So simply +return early in the ERP timeout handler if the FSF request is marked as +dismissed in its status flags. To protect against the race where +zfcp_erp_strategy_check_fsfreq() dismisses and sets +zfcp_fsf_req->erp_action to NULL after our previous status flag check, +return early if zfcp_fsf_req->erp_action is NULL. After all, the former +ERP action does not need to be woken up as that was already done as part of +the dismissal above [zfcp_erp_action_dismiss()]. + +This fixes the following panic due to kernel page fault in IRQ context: + +Unable to handle kernel pointer dereference in virtual kernel address space +Failing address: 0000000000000000 TEID: 0000000000000483 +Fault in home space mode while using kernel ASCE. +AS:000009859238c00b R2:00000e3e7ffd000b R3:00000e3e7ffcc007 S:00000e3e7ffd7000 P:000000000000013d +Oops: 0004 ilc:2 [#1] SMP +Modules linked in: ... +CPU: 82 PID: 311273 Comm: stress Kdump: loaded Tainted: G E X ... +Hardware name: IBM 8561 T01 701 (LPAR) +Krnl PSW : 0404c00180000000 001fffff80549be0 (zfcp_erp_notify+0x40/0xc0 [zfcp]) + R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3 +Krnl GPRS: 0000000000000080 00000e3d00000000 00000000000000f0 0000000000030000 + 000000010028e700 000000000400a39c 000000010028e700 00000e3e7cf87e02 + 0000000010000000 0700098591cb67f0 0000000000000000 0000000000000000 + 0000033840e9a000 0000000000000000 001fffe008d6bc18 001fffe008d6bbc8 +Krnl Code: 001fffff80549bd4: a7180000 lhi %r1,0 + 001fffff80549bd8: 4120a0f0 la %r2,240(%r10) + #001fffff80549bdc: a53e0003 llilh %r3,3 + >001fffff80549be0: ba132000 cs %r1,%r3,0(%r2) + 001fffff80549be4: a7740037 brc 7,1fffff80549c52 + 001fffff80549be8: e320b0180004 lg %r2,24(%r11) + 001fffff80549bee: e31020e00004 lg %r1,224(%r2) + 001fffff80549bf4: 412020e0 la %r2,224(%r2) +Call Trace: + [<001fffff80549be0>] zfcp_erp_notify+0x40/0xc0 [zfcp] + [<00000985915e26f0>] call_timer_fn+0x38/0x190 + [<00000985915e2944>] expire_timers+0xfc/0x190 + [<00000985915e2ac4>] run_timer_softirq+0xec/0x218 + [<0000098591ca7c4c>] __do_softirq+0x144/0x398 + [<00000985915110aa>] do_softirq_own_stack+0x72/0x88 + [<0000098591551b58>] irq_exit+0xb0/0xb8 + [<0000098591510c6a>] do_IRQ+0x82/0xb0 + [<0000098591ca7140>] ext_int_handler+0x128/0x12c + [<0000098591722d98>] clear_subpage.constprop.13+0x38/0x60 +([<000009859172ae4c>] clear_huge_page+0xec/0x250) + [<000009859177e7a2>] do_huge_pmd_anonymous_page+0x32a/0x768 + [<000009859172a712>] __handle_mm_fault+0x88a/0x900 + [<000009859172a860>] handle_mm_fault+0xd8/0x1b0 + [<0000098591529ef6>] do_dat_exception+0x136/0x3e8 + [<0000098591ca6d34>] pgm_check_handler+0x1c8/0x220 +Last Breaking-Event-Address: + [<001fffff80549c88>] zfcp_erp_timeout_handler+0x10/0x18 [zfcp] +Kernel panic - not syncing: Fatal exception in interrupt + +Link: https://lore.kernel.org/r/20200623140242.98864-1-maier@linux.ibm.com +Fixes: 75492a51568b ("s390/scsi: Convert timers to use timer_setup()") +Cc: #4.15+ +Reviewed-by: Julian Wiedmann +Signed-off-by: Steffen Maier +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/s390/scsi/zfcp_erp.c | 13 +++++++++++-- + 1 file changed, 11 insertions(+), 2 deletions(-) + +--- a/drivers/s390/scsi/zfcp_erp.c ++++ b/drivers/s390/scsi/zfcp_erp.c +@@ -592,7 +592,10 @@ static void zfcp_erp_strategy_check_fsfr + ZFCP_STATUS_ERP_TIMEDOUT)) { + req->status |= ZFCP_STATUS_FSFREQ_DISMISSED; + zfcp_dbf_rec_run("erscf_1", act); +- req->erp_action = NULL; ++ /* lock-free concurrent access with ++ * zfcp_erp_timeout_handler() ++ */ ++ WRITE_ONCE(req->erp_action, NULL); + } + if (act->status & ZFCP_STATUS_ERP_TIMEDOUT) + zfcp_dbf_rec_run("erscf_2", act); +@@ -628,8 +631,14 @@ void zfcp_erp_notify(struct zfcp_erp_act + void zfcp_erp_timeout_handler(struct timer_list *t) + { + struct zfcp_fsf_req *fsf_req = from_timer(fsf_req, t, timer); +- struct zfcp_erp_action *act = fsf_req->erp_action; ++ struct zfcp_erp_action *act; + ++ if (fsf_req->status & ZFCP_STATUS_FSFREQ_DISMISSED) ++ return; ++ /* lock-free concurrent access with zfcp_erp_strategy_check_fsfreq() */ ++ act = READ_ONCE(fsf_req->erp_action); ++ if (!act) ++ return; + zfcp_erp_notify(act, ZFCP_STATUS_ERP_TIMEDOUT); + } + diff --git a/queue-4.19/series b/queue-4.19/series index eb46a5081d2..ace56feeac6 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -49,3 +49,8 @@ usb-typec-tcpci_rt1711h-avoid-screaming-irq-causing-boot-hangs.patch alsa-usb-audio-add-quirk-for-denon-dcd-1500re.patch alsa-usb-audio-add-quirk-for-samsung-usbc-headset-akg.patch alsa-usb-audio-fix-oob-access-of-mixer-element-list.patch +scsi-zfcp-fix-panic-on-erp-timeout-for-previously-dismissed-erp-action.patch +xhci-fix-incorrect-ep_state_mask.patch +xhci-fix-enumeration-issue-when-setting-max-packet-size-for-fs-devices.patch +xhci-return-if-xhci-doesn-t-support-lpm.patch +cdc-acm-add-disable_echo-quirk-for-microchip-smsc-chip.patch diff --git a/queue-4.19/xhci-fix-enumeration-issue-when-setting-max-packet-size-for-fs-devices.patch b/queue-4.19/xhci-fix-enumeration-issue-when-setting-max-packet-size-for-fs-devices.patch new file mode 100644 index 00000000000..235dc20751e --- /dev/null +++ b/queue-4.19/xhci-fix-enumeration-issue-when-setting-max-packet-size-for-fs-devices.patch @@ -0,0 +1,44 @@ +From a73d9d9cfc3cfceabd91fb0b0c13e4062b6dbcd7 Mon Sep 17 00:00:00 2001 +From: Al Cooper +Date: Wed, 24 Jun 2020 16:59:46 +0300 +Subject: xhci: Fix enumeration issue when setting max packet size for FS devices. + +From: Al Cooper + +commit a73d9d9cfc3cfceabd91fb0b0c13e4062b6dbcd7 upstream. + +Unable to complete the enumeration of a USB TV Tuner device. + +Per XHCI spec (4.6.5), the EP state field of the input context shall +be cleared for a set address command. In the special case of an FS +device that has "MaxPacketSize0 = 8", the Linux XHCI driver does +not do this before evaluating the context. With an XHCI controller +that checks the EP state field for parameter context error this +causes a problem in cases such as the device getting reset again +after enumeration. + +When that field is cleared, the problem does not occur. + +This was found and fixed by Sasi Kumar. + +Cc: stable@vger.kernel.org +Signed-off-by: Al Cooper +Signed-off-by: Mathias Nyman +Link: https://lore.kernel.org/r/20200624135949.22611-3-mathias.nyman@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/host/xhci.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/usb/host/xhci.c ++++ b/drivers/usb/host/xhci.c +@@ -1405,6 +1405,7 @@ static int xhci_check_maxpacket(struct x + xhci->devs[slot_id]->out_ctx, ep_index); + + ep_ctx = xhci_get_ep_ctx(xhci, command->in_ctx, ep_index); ++ ep_ctx->ep_info &= cpu_to_le32(~EP_STATE_MASK);/* must clear */ + ep_ctx->ep_info2 &= cpu_to_le32(~MAX_PACKET_MASK); + ep_ctx->ep_info2 |= cpu_to_le32(MAX_PACKET(max_packet_size)); + diff --git a/queue-4.19/xhci-fix-incorrect-ep_state_mask.patch b/queue-4.19/xhci-fix-incorrect-ep_state_mask.patch new file mode 100644 index 00000000000..d2f62d04579 --- /dev/null +++ b/queue-4.19/xhci-fix-incorrect-ep_state_mask.patch @@ -0,0 +1,37 @@ +From dceea67058fe22075db3aed62d5cb62092be5053 Mon Sep 17 00:00:00 2001 +From: Mathias Nyman +Date: Wed, 24 Jun 2020 16:59:45 +0300 +Subject: xhci: Fix incorrect EP_STATE_MASK + +From: Mathias Nyman + +commit dceea67058fe22075db3aed62d5cb62092be5053 upstream. + +EP_STATE_MASK should be 0x7 instead of 0xf + +xhci spec 6.2.3 shows that the EP state field in the endpoint context data +structure consist of bits [2:0]. +The old value included a bit from the next field which fortunately is a + RsvdZ region. So hopefully this hasn't caused too much harm + +Cc: stable@vger.kernel.org +Signed-off-by: Mathias Nyman +Link: https://lore.kernel.org/r/20200624135949.22611-2-mathias.nyman@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/host/xhci.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/usb/host/xhci.h ++++ b/drivers/usb/host/xhci.h +@@ -716,7 +716,7 @@ struct xhci_ep_ctx { + * 4 - TRB error + * 5-7 - reserved + */ +-#define EP_STATE_MASK (0xf) ++#define EP_STATE_MASK (0x7) + #define EP_STATE_DISABLED 0 + #define EP_STATE_RUNNING 1 + #define EP_STATE_HALTED 2 diff --git a/queue-4.19/xhci-return-if-xhci-doesn-t-support-lpm.patch b/queue-4.19/xhci-return-if-xhci-doesn-t-support-lpm.patch new file mode 100644 index 00000000000..39d2de0f314 --- /dev/null +++ b/queue-4.19/xhci-return-if-xhci-doesn-t-support-lpm.patch @@ -0,0 +1,48 @@ +From f0c472a6da51f9fac15e80fe2fd9c83b68754cff Mon Sep 17 00:00:00 2001 +From: Kai-Heng Feng +Date: Wed, 24 Jun 2020 16:59:48 +0300 +Subject: xhci: Return if xHCI doesn't support LPM + +From: Kai-Heng Feng + +commit f0c472a6da51f9fac15e80fe2fd9c83b68754cff upstream. + +Just return if xHCI is quirked to disable LPM. We can save some time +from reading registers and doing spinlocks. + +Add stable tag as we want this patch together with the next one, +"Poll for U0 after disabling USB2 LPM" which fixes a suspend issue +for some USB2 LPM devices + +Cc: stable@vger.kernel.org +Signed-off-by: Kai-Heng Feng +Signed-off-by: Mathias Nyman +Link: https://lore.kernel.org/r/20200624135949.22611-5-mathias.nyman@linux.intel.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/host/xhci.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +--- a/drivers/usb/host/xhci.c ++++ b/drivers/usb/host/xhci.c +@@ -4305,6 +4305,9 @@ static int xhci_set_usb2_hardware_lpm(st + int hird, exit_latency; + int ret; + ++ if (xhci->quirks & XHCI_HW_LPM_DISABLE) ++ return -EPERM; ++ + if (hcd->speed >= HCD_USB3 || !xhci->hw_lpm_support || + !udev->lpm_capable) + return -EPERM; +@@ -4327,7 +4330,7 @@ static int xhci_set_usb2_hardware_lpm(st + xhci_dbg(xhci, "%s port %d USB2 hardware LPM\n", + enable ? "enable" : "disable", port_num + 1); + +- if (enable && !(xhci->quirks & XHCI_HW_LPM_DISABLE)) { ++ if (enable) { + /* Host supports BESL timeout instead of HIRD */ + if (udev->usb2_hw_lpm_besl_capable) { + /* if device doesn't have a preferred BESL value use a