From: Greg Kroah-Hartman Date: Sat, 29 Jan 2022 16:13:12 +0000 (+0100) Subject: 4.9-stable patches X-Git-Tag: v5.4.176~79 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=b27a37cf5d6e5df2834253aa201b4b15b13e2e64;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: serial-stm32-fix-software-flow-control-transfer.patch tty-add-support-for-brainboxes-uc-cards.patch tty-n_gsm-fix-sw-flow-control-encoding-handling.patch usb-core-fix-hang-in-usb_kill_urb-by-adding-memory-barriers.patch usb-gadget-f_sourcesink-fix-isoc-transfer-for-usb_speed_super_plus.patch usb-storage-add-unusual-devs-entry-for-vl817-usb-sata-bridge.patch --- diff --git a/queue-4.9/serial-stm32-fix-software-flow-control-transfer.patch b/queue-4.9/serial-stm32-fix-software-flow-control-transfer.patch new file mode 100644 index 00000000000..45dae808c3b --- /dev/null +++ b/queue-4.9/serial-stm32-fix-software-flow-control-transfer.patch @@ -0,0 +1,34 @@ +From 037b91ec7729524107982e36ec4b40f9b174f7a2 Mon Sep 17 00:00:00 2001 +From: Valentin Caron +Date: Tue, 11 Jan 2022 17:44:41 +0100 +Subject: serial: stm32: fix software flow control transfer + +From: Valentin Caron + +commit 037b91ec7729524107982e36ec4b40f9b174f7a2 upstream. + +x_char is ignored by stm32_usart_start_tx() when xmit buffer is empty. + +Fix start_tx condition to allow x_char to be sent. + +Fixes: 48a6092fb41f ("serial: stm32-usart: Add STM32 USART Driver") +Cc: stable +Signed-off-by: Erwan Le Ray +Signed-off-by: Valentin Caron +Link: https://lore.kernel.org/r/20220111164441.6178-3-valentin.caron@foss.st.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/stm32-usart.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/tty/serial/stm32-usart.c ++++ b/drivers/tty/serial/stm32-usart.c +@@ -389,7 +389,7 @@ static void stm32_start_tx(struct uart_p + { + struct circ_buf *xmit = &port->state->xmit; + +- if (uart_circ_empty(xmit)) ++ if (uart_circ_empty(xmit) && !port->x_char) + return; + + stm32_transmit_chars(port); diff --git a/queue-4.9/series b/queue-4.9/series index e4d955eecc2..c339ea57a78 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -5,3 +5,9 @@ scsi-zfcp-fix-failed-recovery-on-gone-remote-port-with-non-npiv-fcp-devices.patc udf-restore-i_lenalloc-when-inode-expansion-fails.patch udf-fix-null-ptr-deref-when-converting-from-inline-format.patch pm-wakeup-simplify-the-output-logic-of-pm_show_wakelocks.patch +serial-stm32-fix-software-flow-control-transfer.patch +tty-n_gsm-fix-sw-flow-control-encoding-handling.patch +tty-add-support-for-brainboxes-uc-cards.patch +usb-storage-add-unusual-devs-entry-for-vl817-usb-sata-bridge.patch +usb-gadget-f_sourcesink-fix-isoc-transfer-for-usb_speed_super_plus.patch +usb-core-fix-hang-in-usb_kill_urb-by-adding-memory-barriers.patch diff --git a/queue-4.9/tty-add-support-for-brainboxes-uc-cards.patch b/queue-4.9/tty-add-support-for-brainboxes-uc-cards.patch new file mode 100644 index 00000000000..5fe3f7f1a69 --- /dev/null +++ b/queue-4.9/tty-add-support-for-brainboxes-uc-cards.patch @@ -0,0 +1,139 @@ +From 152d1afa834c84530828ee031cf07a00e0fc0b8c Mon Sep 17 00:00:00 2001 +From: Cameron Williams +Date: Mon, 24 Jan 2022 09:42:23 +0000 +Subject: tty: Add support for Brainboxes UC cards. + +From: Cameron Williams + +commit 152d1afa834c84530828ee031cf07a00e0fc0b8c upstream. + +This commit adds support for the some of the Brainboxes PCI range of +cards, including the UC-101, UC-235/246, UC-257, UC-268, UC-275/279, +UC-302, UC-310, UC-313, UC-320/324, UC-346, UC-357, UC-368 +and UC-420/431. + +Signed-off-by: Cameron Williams +Cc: stable +Link: https://lore.kernel.org/r/AM5PR0202MB2564688493F7DD9B9C610827C45E9@AM5PR0202MB2564.eurprd02.prod.outlook.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/8250/8250_pci.c | 100 ++++++++++++++++++++++++++++++++++++- + 1 file changed, 98 insertions(+), 2 deletions(-) + +--- a/drivers/tty/serial/8250/8250_pci.c ++++ b/drivers/tty/serial/8250/8250_pci.c +@@ -5238,8 +5238,30 @@ static struct pci_device_id serial_pci_t + { PCI_VENDOR_ID_INTASHIELD, PCI_DEVICE_ID_INTASHIELD_IS400, + PCI_ANY_ID, PCI_ANY_ID, 0, 0, /* 135a.0dc0 */ + pbn_b2_4_115200 }, ++ /* Brainboxes Devices */ + /* +- * BrainBoxes UC-260 ++ * Brainboxes UC-101 ++ */ ++ { PCI_VENDOR_ID_INTASHIELD, 0x0BA1, ++ PCI_ANY_ID, PCI_ANY_ID, ++ 0, 0, ++ pbn_b2_2_115200 }, ++ /* ++ * Brainboxes UC-235/246 ++ */ ++ { PCI_VENDOR_ID_INTASHIELD, 0x0AA1, ++ PCI_ANY_ID, PCI_ANY_ID, ++ 0, 0, ++ pbn_b2_1_115200 }, ++ /* ++ * Brainboxes UC-257 ++ */ ++ { PCI_VENDOR_ID_INTASHIELD, 0x0861, ++ PCI_ANY_ID, PCI_ANY_ID, ++ 0, 0, ++ pbn_b2_2_115200 }, ++ /* ++ * Brainboxes UC-260/271/701/756 + */ + { PCI_VENDOR_ID_INTASHIELD, 0x0D21, + PCI_ANY_ID, PCI_ANY_ID, +@@ -5247,7 +5269,81 @@ static struct pci_device_id serial_pci_t + pbn_b2_4_115200 }, + { PCI_VENDOR_ID_INTASHIELD, 0x0E34, + PCI_ANY_ID, PCI_ANY_ID, +- PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00, ++ PCI_CLASS_COMMUNICATION_MULTISERIAL << 8, 0xffff00, ++ pbn_b2_4_115200 }, ++ /* ++ * Brainboxes UC-268 ++ */ ++ { PCI_VENDOR_ID_INTASHIELD, 0x0841, ++ PCI_ANY_ID, PCI_ANY_ID, ++ 0, 0, ++ pbn_b2_4_115200 }, ++ /* ++ * Brainboxes UC-275/279 ++ */ ++ { PCI_VENDOR_ID_INTASHIELD, 0x0881, ++ PCI_ANY_ID, PCI_ANY_ID, ++ 0, 0, ++ pbn_b2_8_115200 }, ++ /* ++ * Brainboxes UC-302 ++ */ ++ { PCI_VENDOR_ID_INTASHIELD, 0x08E1, ++ PCI_ANY_ID, PCI_ANY_ID, ++ 0, 0, ++ pbn_b2_2_115200 }, ++ /* ++ * Brainboxes UC-310 ++ */ ++ { PCI_VENDOR_ID_INTASHIELD, 0x08C1, ++ PCI_ANY_ID, PCI_ANY_ID, ++ 0, 0, ++ pbn_b2_2_115200 }, ++ /* ++ * Brainboxes UC-313 ++ */ ++ { PCI_VENDOR_ID_INTASHIELD, 0x08A3, ++ PCI_ANY_ID, PCI_ANY_ID, ++ 0, 0, ++ pbn_b2_2_115200 }, ++ /* ++ * Brainboxes UC-320/324 ++ */ ++ { PCI_VENDOR_ID_INTASHIELD, 0x0A61, ++ PCI_ANY_ID, PCI_ANY_ID, ++ 0, 0, ++ pbn_b2_1_115200 }, ++ /* ++ * Brainboxes UC-346 ++ */ ++ { PCI_VENDOR_ID_INTASHIELD, 0x0B02, ++ PCI_ANY_ID, PCI_ANY_ID, ++ 0, 0, ++ pbn_b2_4_115200 }, ++ /* ++ * Brainboxes UC-357 ++ */ ++ { PCI_VENDOR_ID_INTASHIELD, 0x0A81, ++ PCI_ANY_ID, PCI_ANY_ID, ++ 0, 0, ++ pbn_b2_2_115200 }, ++ { PCI_VENDOR_ID_INTASHIELD, 0x0A83, ++ PCI_ANY_ID, PCI_ANY_ID, ++ 0, 0, ++ pbn_b2_2_115200 }, ++ /* ++ * Brainboxes UC-368 ++ */ ++ { PCI_VENDOR_ID_INTASHIELD, 0x0C41, ++ PCI_ANY_ID, PCI_ANY_ID, ++ 0, 0, ++ pbn_b2_4_115200 }, ++ /* ++ * Brainboxes UC-420/431 ++ */ ++ { PCI_VENDOR_ID_INTASHIELD, 0x0921, ++ PCI_ANY_ID, PCI_ANY_ID, ++ 0, 0, + pbn_b2_4_115200 }, + /* + * Perle PCI-RAS cards diff --git a/queue-4.9/tty-n_gsm-fix-sw-flow-control-encoding-handling.patch b/queue-4.9/tty-n_gsm-fix-sw-flow-control-encoding-handling.patch new file mode 100644 index 00000000000..3d8e58bc9af --- /dev/null +++ b/queue-4.9/tty-n_gsm-fix-sw-flow-control-encoding-handling.patch @@ -0,0 +1,64 @@ +From 8838b2af23caf1ff0610caef2795d6668a013b2d Mon Sep 17 00:00:00 2001 +From: "daniel.starke@siemens.com" +Date: Thu, 20 Jan 2022 02:18:57 -0800 +Subject: tty: n_gsm: fix SW flow control encoding/handling + +From: daniel.starke@siemens.com + +commit 8838b2af23caf1ff0610caef2795d6668a013b2d upstream. + +n_gsm is based on the 3GPP 07.010 and its newer version is the 3GPP 27.010. +See https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1516 +The changes from 07.010 to 27.010 are non-functional. Therefore, I refer to +the newer 27.010 here. Chapter 5.2.7.3 states that DC1 (XON) and DC3 (XOFF) +are the control characters defined in ISO/IEC 646. These shall be quoted if +seen in the data stream to avoid interpretation as flow control characters. + +ISO/IEC 646 refers to the set of ISO standards described as the ISO +7-bit coded character set for information interchange. Its final version +is also known as ITU T.50. +See https://www.itu.int/rec/T-REC-T.50-199209-I/en + +To abide the standard it is needed to quote DC1 and DC3 correctly if these +are seen as data bytes and not as control characters. The current +implementation already tries to enforce this but fails to catch all +defined cases. 3GPP 27.010 chapter 5.2.7.3 clearly states that the most +significant bit shall be ignored for DC1 and DC3 handling. The current +implementation handles only the case with the most significant bit set 0. +Cases in which DC1 and DC3 have the most significant bit set 1 are left +unhandled. + +This patch fixes this by masking the data bytes with ISO_IEC_646_MASK (only +the 7 least significant bits set 1) before comparing them with XON +(a.k.a. DC1) and XOFF (a.k.a. DC3) when testing which byte values need +quotation via byte stuffing. + +Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") +Cc: stable@vger.kernel.org +Signed-off-by: Daniel Starke +Link: https://lore.kernel.org/r/20220120101857.2509-1-daniel.starke@siemens.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/n_gsm.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/tty/n_gsm.c ++++ b/drivers/tty/n_gsm.c +@@ -329,6 +329,7 @@ static struct tty_driver *gsm_tty_driver + #define GSM1_ESCAPE_BITS 0x20 + #define XON 0x11 + #define XOFF 0x13 ++#define ISO_IEC_646_MASK 0x7F + + static const struct tty_port_operations gsm_port_ops; + +@@ -547,7 +548,8 @@ static int gsm_stuff_frame(const u8 *inp + int olen = 0; + while (len--) { + if (*input == GSM1_SOF || *input == GSM1_ESCAPE +- || *input == XON || *input == XOFF) { ++ || (*input & ISO_IEC_646_MASK) == XON ++ || (*input & ISO_IEC_646_MASK) == XOFF) { + *output++ = GSM1_ESCAPE; + *output++ = *input++ ^ GSM1_ESCAPE_BITS; + olen++; diff --git a/queue-4.9/usb-core-fix-hang-in-usb_kill_urb-by-adding-memory-barriers.patch b/queue-4.9/usb-core-fix-hang-in-usb_kill_urb-by-adding-memory-barriers.patch new file mode 100644 index 00000000000..f3563b6ed11 --- /dev/null +++ b/queue-4.9/usb-core-fix-hang-in-usb_kill_urb-by-adding-memory-barriers.patch @@ -0,0 +1,128 @@ +From 26fbe9772b8c459687930511444ce443011f86bf Mon Sep 17 00:00:00 2001 +From: Alan Stern +Date: Mon, 24 Jan 2022 15:23:45 -0500 +Subject: USB: core: Fix hang in usb_kill_urb by adding memory barriers + +From: Alan Stern + +commit 26fbe9772b8c459687930511444ce443011f86bf upstream. + +The syzbot fuzzer has identified a bug in which processes hang waiting +for usb_kill_urb() to return. It turns out the issue is not unlinking +the URB; that works just fine. Rather, the problem arises when the +wakeup notification that the URB has completed is not received. + +The reason is memory-access ordering on SMP systems. In outline form, +usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on +different CPUs perform the following actions: + +CPU 0 CPU 1 +---------------------------- --------------------------------- +usb_kill_urb(): __usb_hcd_giveback_urb(): + ... ... + atomic_inc(&urb->reject); atomic_dec(&urb->use_count); + ... ... + wait_event(usb_kill_urb_queue, + atomic_read(&urb->use_count) == 0); + if (atomic_read(&urb->reject)) + wake_up(&usb_kill_urb_queue); + +Confining your attention to urb->reject and urb->use_count, you can +see that the overall pattern of accesses on CPU 0 is: + + write urb->reject, then read urb->use_count; + +whereas the overall pattern of accesses on CPU 1 is: + + write urb->use_count, then read urb->reject. + +This pattern is referred to in memory-model circles as SB (for "Store +Buffering"), and it is well known that without suitable enforcement of +the desired order of accesses -- in the form of memory barriers -- it +is entirely possible for one or both CPUs to execute their reads ahead +of their writes. The end result will be that sometimes CPU 0 sees the +old un-decremented value of urb->use_count while CPU 1 sees the old +un-incremented value of urb->reject. Consequently CPU 0 ends up on +the wait queue and never gets woken up, leading to the observed hang +in usb_kill_urb(). + +The same pattern of accesses occurs in usb_poison_urb() and the +failure pathway of usb_hcd_submit_urb(). + +The problem is fixed by adding suitable memory barriers. To provide +proper memory-access ordering in the SB pattern, a full barrier is +required on both CPUs. The atomic_inc() and atomic_dec() accesses +themselves don't provide any memory ordering, but since they are +present, we can use the optimized smp_mb__after_atomic() memory +barrier in the various routines to obtain the desired effect. + +This patch adds the necessary memory barriers. + +CC: +Reported-and-tested-by: syzbot+76629376e06e2c2ad626@syzkaller.appspotmail.com +Signed-off-by: Alan Stern +Link: https://lore.kernel.org/r/Ye8K0QYee0Q0Nna2@rowland.harvard.edu +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/core/hcd.c | 14 ++++++++++++++ + drivers/usb/core/urb.c | 12 ++++++++++++ + 2 files changed, 26 insertions(+) + +--- a/drivers/usb/core/hcd.c ++++ b/drivers/usb/core/hcd.c +@@ -1668,6 +1668,13 @@ int usb_hcd_submit_urb (struct urb *urb, + urb->hcpriv = NULL; + INIT_LIST_HEAD(&urb->urb_list); + atomic_dec(&urb->use_count); ++ /* ++ * Order the write of urb->use_count above before the read ++ * of urb->reject below. Pairs with the memory barriers in ++ * usb_kill_urb() and usb_poison_urb(). ++ */ ++ smp_mb__after_atomic(); ++ + atomic_dec(&urb->dev->urbnum); + if (atomic_read(&urb->reject)) + wake_up(&usb_kill_urb_queue); +@@ -1777,6 +1784,13 @@ static void __usb_hcd_giveback_urb(struc + + usb_anchor_resume_wakeups(anchor); + atomic_dec(&urb->use_count); ++ /* ++ * Order the write of urb->use_count above before the read ++ * of urb->reject below. Pairs with the memory barriers in ++ * usb_kill_urb() and usb_poison_urb(). ++ */ ++ smp_mb__after_atomic(); ++ + if (unlikely(atomic_read(&urb->reject))) + wake_up(&usb_kill_urb_queue); + usb_put_urb(urb); +--- a/drivers/usb/core/urb.c ++++ b/drivers/usb/core/urb.c +@@ -684,6 +684,12 @@ void usb_kill_urb(struct urb *urb) + if (!(urb && urb->dev && urb->ep)) + return; + atomic_inc(&urb->reject); ++ /* ++ * Order the write of urb->reject above before the read ++ * of urb->use_count below. Pairs with the barriers in ++ * __usb_hcd_giveback_urb() and usb_hcd_submit_urb(). ++ */ ++ smp_mb__after_atomic(); + + usb_hcd_unlink_urb(urb, -ENOENT); + wait_event(usb_kill_urb_queue, atomic_read(&urb->use_count) == 0); +@@ -725,6 +731,12 @@ void usb_poison_urb(struct urb *urb) + if (!urb) + return; + atomic_inc(&urb->reject); ++ /* ++ * Order the write of urb->reject above before the read ++ * of urb->use_count below. Pairs with the barriers in ++ * __usb_hcd_giveback_urb() and usb_hcd_submit_urb(). ++ */ ++ smp_mb__after_atomic(); + + if (!urb->dev || !urb->ep) + return; diff --git a/queue-4.9/usb-gadget-f_sourcesink-fix-isoc-transfer-for-usb_speed_super_plus.patch b/queue-4.9/usb-gadget-f_sourcesink-fix-isoc-transfer-for-usb_speed_super_plus.patch new file mode 100644 index 00000000000..5e5532126ce --- /dev/null +++ b/queue-4.9/usb-gadget-f_sourcesink-fix-isoc-transfer-for-usb_speed_super_plus.patch @@ -0,0 +1,33 @@ +From 904edf8aeb459697129be5fde847e2a502f41fd9 Mon Sep 17 00:00:00 2001 +From: Pavankumar Kondeti +Date: Sat, 22 Jan 2022 08:33:22 +0530 +Subject: usb: gadget: f_sourcesink: Fix isoc transfer for USB_SPEED_SUPER_PLUS + +From: Pavankumar Kondeti + +commit 904edf8aeb459697129be5fde847e2a502f41fd9 upstream. + +Currently when gadget enumerates in super speed plus, the isoc +endpoint request buffer size is not calculated correctly. Fix +this by checking the gadget speed against USB_SPEED_SUPER_PLUS +and update the request buffer size. + +Fixes: 90c4d05780d4 ("usb: fix various gadgets null ptr deref on 10gbps cabling.") +Cc: stable +Signed-off-by: Pavankumar Kondeti +Link: https://lore.kernel.org/r/1642820602-20619-1-git-send-email-quic_pkondeti@quicinc.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/gadget/function/f_sourcesink.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/usb/gadget/function/f_sourcesink.c ++++ b/drivers/usb/gadget/function/f_sourcesink.c +@@ -587,6 +587,7 @@ static int source_sink_start_ep(struct f + + if (is_iso) { + switch (speed) { ++ case USB_SPEED_SUPER_PLUS: + case USB_SPEED_SUPER: + size = ss->isoc_maxpacket * + (ss->isoc_mult + 1) * diff --git a/queue-4.9/usb-storage-add-unusual-devs-entry-for-vl817-usb-sata-bridge.patch b/queue-4.9/usb-storage-add-unusual-devs-entry-for-vl817-usb-sata-bridge.patch new file mode 100644 index 00000000000..3f8b5a7baf0 --- /dev/null +++ b/queue-4.9/usb-storage-add-unusual-devs-entry-for-vl817-usb-sata-bridge.patch @@ -0,0 +1,59 @@ +From 5b67b315037250a61861119683e7fcb509deea25 Mon Sep 17 00:00:00 2001 +From: Alan Stern +Date: Mon, 24 Jan 2022 15:14:40 -0500 +Subject: usb-storage: Add unusual-devs entry for VL817 USB-SATA bridge +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Alan Stern + +commit 5b67b315037250a61861119683e7fcb509deea25 upstream. + +Two people have reported (and mentioned numerous other reports on the +web) that VIA's VL817 USB-SATA bridge does not work with the uas +driver. Typical log messages are: + +[ 3606.232149] sd 14:0:0:0: [sdg] tag#2 uas_zap_pending 0 uas-tag 1 inflight: CMD +[ 3606.232154] sd 14:0:0:0: [sdg] tag#2 CDB: Write(16) 8a 00 00 00 00 00 18 0c c9 80 00 00 00 80 00 00 +[ 3606.306257] usb 4-4.4: reset SuperSpeed Plus Gen 2x1 USB device number 11 using xhci_hcd +[ 3606.328584] scsi host14: uas_eh_device_reset_handler success + +Surprisingly, the devices do seem to work okay for some other people. +The cause of the differing behaviors is not known. + +In the hope of getting the devices to work for the most users, even at +the possible cost of degraded performance for some, this patch adds an +unusual_devs entry for the VL817 to block it from binding to the uas +driver by default. Users will be able to override this entry by means +of a module parameter, if they want. + +CC: +Reported-by: DocMAX +Reported-and-tested-by: Thomas Weißschuh +Signed-off-by: Alan Stern +Link: https://lore.kernel.org/r/Ye8IsK2sjlEv1rqU@rowland.harvard.edu +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/storage/unusual_devs.h | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/drivers/usb/storage/unusual_devs.h ++++ b/drivers/usb/storage/unusual_devs.h +@@ -2308,6 +2308,16 @@ UNUSUAL_DEV( 0x2027, 0xa001, 0x0000, 0x + USB_SC_DEVICE, USB_PR_DEVICE, usb_stor_euscsi_init, + US_FL_SCM_MULT_TARG ), + ++/* ++ * Reported by DocMAX ++ * and Thomas Weißschuh ++ */ ++UNUSUAL_DEV( 0x2109, 0x0715, 0x9999, 0x9999, ++ "VIA Labs, Inc.", ++ "VL817 SATA Bridge", ++ USB_SC_DEVICE, USB_PR_DEVICE, NULL, ++ US_FL_IGNORE_UAS), ++ + UNUSUAL_DEV( 0x2116, 0x0320, 0x0001, 0x0001, + "ST", + "2A",