From: Greg Kroah-Hartman Date: Mon, 21 Jun 2021 10:49:18 +0000 (+0200) Subject: 4.19-stable patches X-Git-Tag: v5.4.128~34 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=eafe6ffba8b9d726d73f24b10afa0e93d0cd8aed;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: arcv2-save-abi-registers-across-signal-handling.patch can-bcm-fix-infoleak-in-struct-bcm_msg_head.patch can-mcba_usb-fix-memory-leak-in-mcba_usb.patch pci-add-acs-quirk-for-broadcom-bcm57414-nic.patch pci-mark-some-nvidia-gpus-to-avoid-bus-reset.patch pci-mark-ti-c667x-to-avoid-bus-reset.patch pci-work-around-huawei-intelligent-nic-vf-flr-erratum.patch tracing-do-no-increment-trace_clock_global-by-one.patch tracing-do-not-stop-recording-cmdlines-when-tracing-is-off.patch tracing-do-not-stop-recording-comms-if-the-trace-file-is-being-read.patch usb-core-hub-disable-autosuspend-for-cypress-cy7c65632.patch --- diff --git a/queue-4.19/arcv2-save-abi-registers-across-signal-handling.patch b/queue-4.19/arcv2-save-abi-registers-across-signal-handling.patch new file mode 100644 index 00000000000..3c2a12336de --- /dev/null +++ b/queue-4.19/arcv2-save-abi-registers-across-signal-handling.patch @@ -0,0 +1,112 @@ +From 96f1b00138cb8f04c742c82d0a7c460b2202e887 Mon Sep 17 00:00:00 2001 +From: Vineet Gupta +Date: Tue, 8 Jun 2021 19:39:25 -0700 +Subject: ARCv2: save ABI registers across signal handling + +From: Vineet Gupta + +commit 96f1b00138cb8f04c742c82d0a7c460b2202e887 upstream. + +ARCv2 has some configuration dependent registers (r30, r58, r59) which +could be targetted by the compiler. To keep the ABI stable, these were +unconditionally part of the glibc ABI +(sysdeps/unix/sysv/linux/arc/sys/ucontext.h:mcontext_t) however we +missed populating them (by saving/restoring them across signal +handling). + +This patch fixes the issue by + - adding arcv2 ABI regs to kernel struct sigcontext + - populating them during signal handling + +Change to struct sigcontext might seem like a glibc ABI change (although +it primarily uses ucontext_t:mcontext_t) but the fact is + - it has only been extended (existing fields are not touched) + - the old sigcontext was ABI incomplete to begin with anyways + +Fixes: https://github.com/foss-for-synopsys-dwc-arc-processors/linux/issues/53 +Cc: +Tested-by: kernel test robot +Reported-by: Vladimir Isaev +Signed-off-by: Vineet Gupta +Signed-off-by: Greg Kroah-Hartman +--- + arch/arc/include/uapi/asm/sigcontext.h | 1 + arch/arc/kernel/signal.c | 43 +++++++++++++++++++++++++++++++++ + 2 files changed, 44 insertions(+) + +--- a/arch/arc/include/uapi/asm/sigcontext.h ++++ b/arch/arc/include/uapi/asm/sigcontext.h +@@ -18,6 +18,7 @@ + */ + struct sigcontext { + struct user_regs_struct regs; ++ struct user_regs_arcv2 v2abi; + }; + + #endif /* _ASM_ARC_SIGCONTEXT_H */ +--- a/arch/arc/kernel/signal.c ++++ b/arch/arc/kernel/signal.c +@@ -64,6 +64,41 @@ struct rt_sigframe { + unsigned int sigret_magic; + }; + ++static int save_arcv2_regs(struct sigcontext *mctx, struct pt_regs *regs) ++{ ++ int err = 0; ++#ifndef CONFIG_ISA_ARCOMPACT ++ struct user_regs_arcv2 v2abi; ++ ++ v2abi.r30 = regs->r30; ++#ifdef CONFIG_ARC_HAS_ACCL_REGS ++ v2abi.r58 = regs->r58; ++ v2abi.r59 = regs->r59; ++#else ++ v2abi.r58 = v2abi.r59 = 0; ++#endif ++ err = __copy_to_user(&mctx->v2abi, &v2abi, sizeof(v2abi)); ++#endif ++ return err; ++} ++ ++static int restore_arcv2_regs(struct sigcontext *mctx, struct pt_regs *regs) ++{ ++ int err = 0; ++#ifndef CONFIG_ISA_ARCOMPACT ++ struct user_regs_arcv2 v2abi; ++ ++ err = __copy_from_user(&v2abi, &mctx->v2abi, sizeof(v2abi)); ++ ++ regs->r30 = v2abi.r30; ++#ifdef CONFIG_ARC_HAS_ACCL_REGS ++ regs->r58 = v2abi.r58; ++ regs->r59 = v2abi.r59; ++#endif ++#endif ++ return err; ++} ++ + static int + stash_usr_regs(struct rt_sigframe __user *sf, struct pt_regs *regs, + sigset_t *set) +@@ -97,6 +132,10 @@ stash_usr_regs(struct rt_sigframe __user + + err = __copy_to_user(&(sf->uc.uc_mcontext.regs.scratch), &uregs.scratch, + sizeof(sf->uc.uc_mcontext.regs.scratch)); ++ ++ if (is_isa_arcv2()) ++ err |= save_arcv2_regs(&(sf->uc.uc_mcontext), regs); ++ + err |= __copy_to_user(&sf->uc.uc_sigmask, set, sizeof(sigset_t)); + + return err ? -EFAULT : 0; +@@ -112,6 +151,10 @@ static int restore_usr_regs(struct pt_re + err |= __copy_from_user(&uregs.scratch, + &(sf->uc.uc_mcontext.regs.scratch), + sizeof(sf->uc.uc_mcontext.regs.scratch)); ++ ++ if (is_isa_arcv2()) ++ err |= restore_arcv2_regs(&(sf->uc.uc_mcontext), regs); ++ + if (err) + return -EFAULT; + diff --git a/queue-4.19/can-bcm-fix-infoleak-in-struct-bcm_msg_head.patch b/queue-4.19/can-bcm-fix-infoleak-in-struct-bcm_msg_head.patch new file mode 100644 index 00000000000..d53b37819f1 --- /dev/null +++ b/queue-4.19/can-bcm-fix-infoleak-in-struct-bcm_msg_head.patch @@ -0,0 +1,51 @@ +From 5e87ddbe3942e27e939bdc02deb8579b0cbd8ecc Mon Sep 17 00:00:00 2001 +From: Norbert Slusarek +Date: Sat, 12 Jun 2021 22:18:54 +0200 +Subject: can: bcm: fix infoleak in struct bcm_msg_head + +From: Norbert Slusarek + +commit 5e87ddbe3942e27e939bdc02deb8579b0cbd8ecc upstream. + +On 64-bit systems, struct bcm_msg_head has an added padding of 4 bytes between +struct members count and ival1. Even though all struct members are initialized, +the 4-byte hole will contain data from the kernel stack. This patch zeroes out +struct bcm_msg_head before usage, preventing infoleaks to userspace. + +Fixes: ffd980f976e7 ("[CAN]: Add broadcast manager (bcm) protocol") +Link: https://lore.kernel.org/r/trinity-7c1b2e82-e34f-4885-8060-2cd7a13769ce-1623532166177@3c-app-gmx-bs52 +Cc: linux-stable +Signed-off-by: Norbert Slusarek +Acked-by: Oliver Hartkopp +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + net/can/bcm.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/net/can/bcm.c ++++ b/net/can/bcm.c +@@ -393,6 +393,7 @@ static void bcm_tx_timeout_tsklet(unsign + if (!op->count && (op->flags & TX_COUNTEVT)) { + + /* create notification to user */ ++ memset(&msg_head, 0, sizeof(msg_head)); + msg_head.opcode = TX_EXPIRED; + msg_head.flags = op->flags; + msg_head.count = op->count; +@@ -440,6 +441,7 @@ static void bcm_rx_changed(struct bcm_op + /* this element is not throttled anymore */ + data->flags &= (BCM_CAN_FLAGS_MASK|RX_RECV); + ++ memset(&head, 0, sizeof(head)); + head.opcode = RX_CHANGED; + head.flags = op->flags; + head.count = op->count; +@@ -554,6 +556,7 @@ static void bcm_rx_timeout_tsklet(unsign + struct bcm_msg_head msg_head; + + /* create notification to user */ ++ memset(&msg_head, 0, sizeof(msg_head)); + msg_head.opcode = RX_TIMEOUT; + msg_head.flags = op->flags; + msg_head.count = op->count; diff --git a/queue-4.19/can-mcba_usb-fix-memory-leak-in-mcba_usb.patch b/queue-4.19/can-mcba_usb-fix-memory-leak-in-mcba_usb.patch new file mode 100644 index 00000000000..9b7212a8cdd --- /dev/null +++ b/queue-4.19/can-mcba_usb-fix-memory-leak-in-mcba_usb.patch @@ -0,0 +1,101 @@ +From 91c02557174be7f72e46ed7311e3bea1939840b0 Mon Sep 17 00:00:00 2001 +From: Pavel Skripkin +Date: Thu, 10 Jun 2021 00:58:33 +0300 +Subject: can: mcba_usb: fix memory leak in mcba_usb + +From: Pavel Skripkin + +commit 91c02557174be7f72e46ed7311e3bea1939840b0 upstream. + +Syzbot reported memory leak in SocketCAN driver for Microchip CAN BUS +Analyzer Tool. The problem was in unfreed usb_coherent. + +In mcba_usb_start() 20 coherent buffers are allocated and there is +nothing, that frees them: + +1) In callback function the urb is resubmitted and that's all +2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER + is not set (see mcba_usb_start) and this flag cannot be used with + coherent buffers. + +Fail log: +| [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected +| [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem) + +So, all allocated buffers should be freed with usb_free_coherent() +explicitly + +NOTE: +The same pattern for allocating and freeing coherent buffers +is used in drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c + +Fixes: 51f3baad7de9 ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer") +Link: https://lore.kernel.org/r/20210609215833.30393-1-paskripkin@gmail.com +Cc: linux-stable +Reported-and-tested-by: syzbot+57281c762a3922e14dfe@syzkaller.appspotmail.com +Signed-off-by: Pavel Skripkin +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/can/usb/mcba_usb.c | 17 +++++++++++++++-- + 1 file changed, 15 insertions(+), 2 deletions(-) + +--- a/drivers/net/can/usb/mcba_usb.c ++++ b/drivers/net/can/usb/mcba_usb.c +@@ -93,6 +93,8 @@ struct mcba_priv { + bool can_ka_first_pass; + bool can_speed_check; + atomic_t free_ctx_cnt; ++ void *rxbuf[MCBA_MAX_RX_URBS]; ++ dma_addr_t rxbuf_dma[MCBA_MAX_RX_URBS]; + }; + + /* CAN frame */ +@@ -644,6 +646,7 @@ static int mcba_usb_start(struct mcba_pr + for (i = 0; i < MCBA_MAX_RX_URBS; i++) { + struct urb *urb = NULL; + u8 *buf; ++ dma_addr_t buf_dma; + + /* create a URB, and a buffer for it */ + urb = usb_alloc_urb(0, GFP_KERNEL); +@@ -653,7 +656,7 @@ static int mcba_usb_start(struct mcba_pr + } + + buf = usb_alloc_coherent(priv->udev, MCBA_USB_RX_BUFF_SIZE, +- GFP_KERNEL, &urb->transfer_dma); ++ GFP_KERNEL, &buf_dma); + if (!buf) { + netdev_err(netdev, "No memory left for USB buffer\n"); + usb_free_urb(urb); +@@ -672,11 +675,14 @@ static int mcba_usb_start(struct mcba_pr + if (err) { + usb_unanchor_urb(urb); + usb_free_coherent(priv->udev, MCBA_USB_RX_BUFF_SIZE, +- buf, urb->transfer_dma); ++ buf, buf_dma); + usb_free_urb(urb); + break; + } + ++ priv->rxbuf[i] = buf; ++ priv->rxbuf_dma[i] = buf_dma; ++ + /* Drop reference, USB core will take care of freeing it */ + usb_free_urb(urb); + } +@@ -719,7 +725,14 @@ static int mcba_usb_open(struct net_devi + + static void mcba_urb_unlink(struct mcba_priv *priv) + { ++ int i; ++ + usb_kill_anchored_urbs(&priv->rx_submitted); ++ ++ for (i = 0; i < MCBA_MAX_RX_URBS; ++i) ++ usb_free_coherent(priv->udev, MCBA_USB_RX_BUFF_SIZE, ++ priv->rxbuf[i], priv->rxbuf_dma[i]); ++ + usb_kill_anchored_urbs(&priv->tx_submitted); + } + diff --git a/queue-4.19/pci-add-acs-quirk-for-broadcom-bcm57414-nic.patch b/queue-4.19/pci-add-acs-quirk-for-broadcom-bcm57414-nic.patch new file mode 100644 index 00000000000..09bf757c23f --- /dev/null +++ b/queue-4.19/pci-add-acs-quirk-for-broadcom-bcm57414-nic.patch @@ -0,0 +1,40 @@ +From db2f77e2bd99dbd2fb23ddde58f0fae392fe3338 Mon Sep 17 00:00:00 2001 +From: Sriharsha Basavapatna +Date: Fri, 21 May 2021 21:13:17 -0400 +Subject: PCI: Add ACS quirk for Broadcom BCM57414 NIC + +From: Sriharsha Basavapatna + +commit db2f77e2bd99dbd2fb23ddde58f0fae392fe3338 upstream. + +The Broadcom BCM57414 NIC may be a multi-function device. While it does +not advertise an ACS capability, peer-to-peer transactions are not possible +between the individual functions, so it is safe to treat them as fully +isolated. + +Add an ACS quirk for this device so the functions can be in independent +IOMMU groups and attached individually to userspace applications using +VFIO. + +[bhelgaas: commit log] +Link: https://lore.kernel.org/r/1621645997-16251-1-git-send-email-michael.chan@broadcom.com +Signed-off-by: Sriharsha Basavapatna +Signed-off-by: Michael Chan +Signed-off-by: Bjorn Helgaas +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/quirks.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/pci/quirks.c ++++ b/drivers/pci/quirks.c +@@ -4711,6 +4711,8 @@ static const struct pci_dev_acs_enabled + { PCI_VENDOR_ID_AMPERE, 0xE00A, pci_quirk_xgene_acs }, + { PCI_VENDOR_ID_AMPERE, 0xE00B, pci_quirk_xgene_acs }, + { PCI_VENDOR_ID_AMPERE, 0xE00C, pci_quirk_xgene_acs }, ++ /* Broadcom multi-function device */ ++ { PCI_VENDOR_ID_BROADCOM, 0x16D7, pci_quirk_mf_endpoint_acs }, + { PCI_VENDOR_ID_BROADCOM, 0xD714, pci_quirk_brcm_acs }, + { 0 } + }; diff --git a/queue-4.19/pci-mark-some-nvidia-gpus-to-avoid-bus-reset.patch b/queue-4.19/pci-mark-some-nvidia-gpus-to-avoid-bus-reset.patch new file mode 100644 index 00000000000..dab7103e909 --- /dev/null +++ b/queue-4.19/pci-mark-some-nvidia-gpus-to-avoid-bus-reset.patch @@ -0,0 +1,48 @@ +From 4c207e7121fa92b66bf1896bf8ccb9edfb0f9731 Mon Sep 17 00:00:00 2001 +From: Shanker Donthineni +Date: Tue, 8 Jun 2021 11:18:56 +0530 +Subject: PCI: Mark some NVIDIA GPUs to avoid bus reset + +From: Shanker Donthineni + +commit 4c207e7121fa92b66bf1896bf8ccb9edfb0f9731 upstream. + +Some NVIDIA GPU devices do not work with SBR. Triggering SBR leaves the +device inoperable for the current system boot. It requires a system +hard-reboot to get the GPU device back to normal operating condition +post-SBR. For the affected devices, enable NO_BUS_RESET quirk to avoid the +issue. + +This issue will be fixed in the next generation of hardware. + +Link: https://lore.kernel.org/r/20210608054857.18963-8-ameynarkhede03@gmail.com +Signed-off-by: Shanker Donthineni +Signed-off-by: Bjorn Helgaas +Reviewed-by: Sinan Kaya +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/quirks.c | 12 ++++++++++++ + 1 file changed, 12 insertions(+) + +--- a/drivers/pci/quirks.c ++++ b/drivers/pci/quirks.c +@@ -3464,6 +3464,18 @@ static void quirk_no_bus_reset(struct pc + } + + /* ++ * Some NVIDIA GPU devices do not work with bus reset, SBR needs to be ++ * prevented for those affected devices. ++ */ ++static void quirk_nvidia_no_bus_reset(struct pci_dev *dev) ++{ ++ if ((dev->device & 0xffc0) == 0x2340) ++ quirk_no_bus_reset(dev); ++} ++DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID, ++ quirk_nvidia_no_bus_reset); ++ ++/* + * Some Atheros AR9xxx and QCA988x chips do not behave after a bus reset. + * The device will throw a Link Down error on AER-capable systems and + * regardless of AER, config space of the device is never accessible again diff --git a/queue-4.19/pci-mark-ti-c667x-to-avoid-bus-reset.patch b/queue-4.19/pci-mark-ti-c667x-to-avoid-bus-reset.patch new file mode 100644 index 00000000000..b246159afee --- /dev/null +++ b/queue-4.19/pci-mark-ti-c667x-to-avoid-bus-reset.patch @@ -0,0 +1,48 @@ +From b5cf198e74a91073d12839a3e2db99994a39995d Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Antti=20J=C3=A4rvinen?= +Date: Mon, 15 Mar 2021 10:26:06 +0000 +Subject: PCI: Mark TI C667X to avoid bus reset +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Antti Järvinen + +commit b5cf198e74a91073d12839a3e2db99994a39995d upstream. + +Some TI KeyStone C667X devices do not support bus/hot reset. The PCIESS +automatically disables LTSSM when Secondary Bus Reset is received and +device stops working. Prevent bus reset for these devices. With this +change, the device can be assigned to VMs with VFIO, but it will leak state +between VMs. + +Reference: https://e2e.ti.com/support/processors/f/791/t/954382 +Link: https://lore.kernel.org/r/20210315102606.17153-1-antti.jarvinen@gmail.com +Signed-off-by: Antti Järvinen +Signed-off-by: Bjorn Helgaas +Reviewed-by: Kishon Vijay Abraham I +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/quirks.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/drivers/pci/quirks.c ++++ b/drivers/pci/quirks.c +@@ -3483,6 +3483,16 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_A + */ + DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_CAVIUM, 0xa100, quirk_no_bus_reset); + ++/* ++ * Some TI KeyStone C667X devices do not support bus/hot reset. The PCIESS ++ * automatically disables LTSSM when Secondary Bus Reset is received and ++ * the device stops working. Prevent bus reset for these devices. With ++ * this change, the device can be assigned to VMs with VFIO, but it will ++ * leak state between VMs. Reference ++ * https://e2e.ti.com/support/processors/f/791/t/954382 ++ */ ++DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TI, 0xb005, quirk_no_bus_reset); ++ + static void quirk_no_pm_reset(struct pci_dev *dev) + { + /* diff --git a/queue-4.19/pci-work-around-huawei-intelligent-nic-vf-flr-erratum.patch b/queue-4.19/pci-work-around-huawei-intelligent-nic-vf-flr-erratum.patch new file mode 100644 index 00000000000..100880249cf --- /dev/null +++ b/queue-4.19/pci-work-around-huawei-intelligent-nic-vf-flr-erratum.patch @@ -0,0 +1,117 @@ +From ce00322c2365e1f7b0312f2f493539c833465d97 Mon Sep 17 00:00:00 2001 +From: Chiqijun +Date: Mon, 24 May 2021 17:44:07 -0500 +Subject: PCI: Work around Huawei Intelligent NIC VF FLR erratum + +From: Chiqijun + +commit ce00322c2365e1f7b0312f2f493539c833465d97 upstream. + +pcie_flr() starts a Function Level Reset (FLR), waits 100ms (the maximum +time allowed for FLR completion by PCIe r5.0, sec 6.6.2), and waits for the +FLR to complete. It assumes the FLR is complete when a config read returns +valid data. + +When we do an FLR on several Huawei Intelligent NIC VFs at the same time, +firmware on the NIC processes them serially. The VF may respond to config +reads before the firmware has completed its reset processing. If we bind a +driver to the VF (e.g., by assigning the VF to a virtual machine) in the +interval between the successful config read and completion of the firmware +reset processing, the NIC VF driver may fail to load. + +Prevent this driver failure by waiting for the NIC firmware to complete its +reset processing. Not all NIC firmware supports this feature. + +[bhelgaas: commit log] +Link: https://support.huawei.com/enterprise/en/doc/EDOC1100063073/87950645/vm-oss-occasionally-fail-to-load-the-in200-driver-when-the-vf-performs-flr +Link: https://lore.kernel.org/r/20210414132301.1793-1-chiqijun@huawei.com +Signed-off-by: Chiqijun +Signed-off-by: Bjorn Helgaas +Reviewed-by: Alex Williamson +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/quirks.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++ + 1 file changed, 65 insertions(+) + +--- a/drivers/pci/quirks.c ++++ b/drivers/pci/quirks.c +@@ -3897,6 +3897,69 @@ static int delay_250ms_after_flr(struct + return 0; + } + ++#define PCI_DEVICE_ID_HINIC_VF 0x375E ++#define HINIC_VF_FLR_TYPE 0x1000 ++#define HINIC_VF_FLR_CAP_BIT (1UL << 30) ++#define HINIC_VF_OP 0xE80 ++#define HINIC_VF_FLR_PROC_BIT (1UL << 18) ++#define HINIC_OPERATION_TIMEOUT 15000 /* 15 seconds */ ++ ++/* Device-specific reset method for Huawei Intelligent NIC virtual functions */ ++static int reset_hinic_vf_dev(struct pci_dev *pdev, int probe) ++{ ++ unsigned long timeout; ++ void __iomem *bar; ++ u32 val; ++ ++ if (probe) ++ return 0; ++ ++ bar = pci_iomap(pdev, 0, 0); ++ if (!bar) ++ return -ENOTTY; ++ ++ /* Get and check firmware capabilities */ ++ val = ioread32be(bar + HINIC_VF_FLR_TYPE); ++ if (!(val & HINIC_VF_FLR_CAP_BIT)) { ++ pci_iounmap(pdev, bar); ++ return -ENOTTY; ++ } ++ ++ /* Set HINIC_VF_FLR_PROC_BIT for the start of FLR */ ++ val = ioread32be(bar + HINIC_VF_OP); ++ val = val | HINIC_VF_FLR_PROC_BIT; ++ iowrite32be(val, bar + HINIC_VF_OP); ++ ++ pcie_flr(pdev); ++ ++ /* ++ * The device must recapture its Bus and Device Numbers after FLR ++ * in order generate Completions. Issue a config write to let the ++ * device capture this information. ++ */ ++ pci_write_config_word(pdev, PCI_VENDOR_ID, 0); ++ ++ /* Firmware clears HINIC_VF_FLR_PROC_BIT when reset is complete */ ++ timeout = jiffies + msecs_to_jiffies(HINIC_OPERATION_TIMEOUT); ++ do { ++ val = ioread32be(bar + HINIC_VF_OP); ++ if (!(val & HINIC_VF_FLR_PROC_BIT)) ++ goto reset_complete; ++ msleep(20); ++ } while (time_before(jiffies, timeout)); ++ ++ val = ioread32be(bar + HINIC_VF_OP); ++ if (!(val & HINIC_VF_FLR_PROC_BIT)) ++ goto reset_complete; ++ ++ pci_warn(pdev, "Reset dev timeout, FLR ack reg: %#010x\n", val); ++ ++reset_complete: ++ pci_iounmap(pdev, bar); ++ ++ return 0; ++} ++ + static const struct pci_dev_reset_methods pci_dev_reset_methods[] = { + { PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF, + reset_intel_82599_sfp_virtfn }, +@@ -3908,6 +3971,8 @@ static const struct pci_dev_reset_method + { PCI_VENDOR_ID_INTEL, 0x0953, delay_250ms_after_flr }, + { PCI_VENDOR_ID_CHELSIO, PCI_ANY_ID, + reset_chelsio_generic_dev }, ++ { PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HINIC_VF, ++ reset_hinic_vf_dev }, + { 0 } + }; + diff --git a/queue-4.19/series b/queue-4.19/series index 4678ee9cfb8..5bff9f0e3a4 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -55,3 +55,14 @@ asoc-rt5659-fix-the-lost-powers-for-the-hda-header.patch pinctrl-ralink-rt2880-avoid-to-error-in-calls-is-pin.patch radeon-use-memcpy_to-fromio-for-uvd-fw-upload.patch hwmon-scpi-hwmon-shows-the-negative-temperature-prop.patch +can-bcm-fix-infoleak-in-struct-bcm_msg_head.patch +can-mcba_usb-fix-memory-leak-in-mcba_usb.patch +usb-core-hub-disable-autosuspend-for-cypress-cy7c65632.patch +tracing-do-not-stop-recording-cmdlines-when-tracing-is-off.patch +tracing-do-not-stop-recording-comms-if-the-trace-file-is-being-read.patch +tracing-do-no-increment-trace_clock_global-by-one.patch +pci-mark-ti-c667x-to-avoid-bus-reset.patch +pci-mark-some-nvidia-gpus-to-avoid-bus-reset.patch +pci-add-acs-quirk-for-broadcom-bcm57414-nic.patch +pci-work-around-huawei-intelligent-nic-vf-flr-erratum.patch +arcv2-save-abi-registers-across-signal-handling.patch diff --git a/queue-4.19/tracing-do-no-increment-trace_clock_global-by-one.patch b/queue-4.19/tracing-do-no-increment-trace_clock_global-by-one.patch new file mode 100644 index 00000000000..4fdc12275b1 --- /dev/null +++ b/queue-4.19/tracing-do-no-increment-trace_clock_global-by-one.patch @@ -0,0 +1,131 @@ +From 89529d8b8f8daf92d9979382b8d2eb39966846ea Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (VMware)" +Date: Thu, 17 Jun 2021 17:12:35 -0400 +Subject: tracing: Do no increment trace_clock_global() by one + +From: Steven Rostedt (VMware) + +commit 89529d8b8f8daf92d9979382b8d2eb39966846ea upstream. + +The trace_clock_global() tries to make sure the events between CPUs is +somewhat in order. A global value is used and updated by the latest read +of a clock. If one CPU is ahead by a little, and is read by another CPU, a +lock is taken, and if the timestamp of the other CPU is behind, it will +simply use the other CPUs timestamp. + +The lock is also only taken with a "trylock" due to tracing, and strange +recursions can happen. The lock is not taken at all in NMI context. + +In the case where the lock is not able to be taken, the non synced +timestamp is returned. But it will not be less than the saved global +timestamp. + +The problem arises because when the time goes "backwards" the time +returned is the saved timestamp plus 1. If the lock is not taken, and the +plus one to the timestamp is returned, there's a small race that can cause +the time to go backwards! + + CPU0 CPU1 + ---- ---- + trace_clock_global() { + ts = clock() [ 1000 ] + trylock(clock_lock) [ success ] + global_ts = ts; [ 1000 ] + + + trace_clock_global() { + ts = clock() [ 999 ] + if (ts < global_ts) + ts = global_ts + 1 [ 1001 ] + + trylock(clock_lock) [ fail ] + + return ts [ 1001] + } + unlock(clock_lock); + return ts; [ 1000 ] + } + + trace_clock_global() { + ts = clock() [ 1000 ] + if (ts < global_ts) [ false 1000 == 1000 ] + + trylock(clock_lock) [ success ] + global_ts = ts; [ 1000 ] + unlock(clock_lock) + + return ts; [ 1000 ] + } + +The above case shows to reads of trace_clock_global() on the same CPU, but +the second read returns one less than the first read. That is, time when +backwards, and this is not what is allowed by trace_clock_global(). + +This was triggered by heavy tracing and the ring buffer checker that tests +for the clock going backwards: + + Ring buffer clock went backwards: 20613921464 -> 20613921463 + ------------[ cut here ]------------ + WARNING: CPU: 2 PID: 0 at kernel/trace/ring_buffer.c:3412 check_buffer+0x1b9/0x1c0 + Modules linked in: + [..] + [CPU: 2]TIME DOES NOT MATCH expected:20620711698 actual:20620711697 delta:6790234 before:20613921463 after:20613921463 + [20613915818] PAGE TIME STAMP + [20613915818] delta:0 + [20613915819] delta:1 + [20613916035] delta:216 + [20613916465] delta:430 + [20613916575] delta:110 + [20613916749] delta:174 + [20613917248] delta:499 + [20613917333] delta:85 + [20613917775] delta:442 + [20613917921] delta:146 + [20613918321] delta:400 + [20613918568] delta:247 + [20613918768] delta:200 + [20613919306] delta:538 + [20613919353] delta:47 + [20613919980] delta:627 + [20613920296] delta:316 + [20613920571] delta:275 + [20613920862] delta:291 + [20613921152] delta:290 + [20613921464] delta:312 + [20613921464] delta:0 TIME EXTEND + [20613921464] delta:0 + +This happened more than once, and always for an off by one result. It also +started happening after commit aafe104aa9096 was added. + +Cc: stable@vger.kernel.org +Fixes: aafe104aa9096 ("tracing: Restructure trace_clock_global() to never block") +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace_clock.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/kernel/trace/trace_clock.c ++++ b/kernel/trace/trace_clock.c +@@ -115,9 +115,9 @@ u64 notrace trace_clock_global(void) + prev_time = READ_ONCE(trace_clock_struct.prev_time); + now = sched_clock_cpu(this_cpu); + +- /* Make sure that now is always greater than prev_time */ ++ /* Make sure that now is always greater than or equal to prev_time */ + if ((s64)(now - prev_time) < 0) +- now = prev_time + 1; ++ now = prev_time; + + /* + * If in an NMI context then dont risk lockups and simply return +@@ -131,7 +131,7 @@ u64 notrace trace_clock_global(void) + /* Reread prev_time in case it was already updated */ + prev_time = READ_ONCE(trace_clock_struct.prev_time); + if ((s64)(now - prev_time) < 0) +- now = prev_time + 1; ++ now = prev_time; + + trace_clock_struct.prev_time = now; + diff --git a/queue-4.19/tracing-do-not-stop-recording-cmdlines-when-tracing-is-off.patch b/queue-4.19/tracing-do-not-stop-recording-cmdlines-when-tracing-is-off.patch new file mode 100644 index 00000000000..f90f86dcf07 --- /dev/null +++ b/queue-4.19/tracing-do-not-stop-recording-cmdlines-when-tracing-is-off.patch @@ -0,0 +1,52 @@ +From 85550c83da421fb12dc1816c45012e1e638d2b38 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (VMware)" +Date: Thu, 17 Jun 2021 13:47:25 -0400 +Subject: tracing: Do not stop recording cmdlines when tracing is off + +From: Steven Rostedt (VMware) + +commit 85550c83da421fb12dc1816c45012e1e638d2b38 upstream. + +The saved_cmdlines is used to map pids to the task name, such that the +output of the tracing does not just show pids, but also gives a human +readable name for the task. + +If the name is not mapped, the output looks like this: + + <...>-1316 [005] ...2 132.044039: ... + +Instead of this: + + gnome-shell-1316 [005] ...2 132.044039: ... + +The names are updated when tracing is running, but are skipped if tracing +is stopped. Unfortunately, this stops the recording of the names if the +top level tracer is stopped, and not if there's other tracers active. + +The recording of a name only happens when a new event is written into a +ring buffer, so there is no need to test if tracing is on or not. If +tracing is off, then no event is written and no need to test if tracing is +off or not. + +Remove the check, as it hides the names of tasks for events in the +instance buffers. + +Cc: stable@vger.kernel.org +Fixes: 7ffbd48d5cab2 ("tracing: Cache comms only after an event occurred") +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace.c | 2 -- + 1 file changed, 2 deletions(-) + +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -2031,8 +2031,6 @@ static bool tracing_record_taskinfo_skip + { + if (unlikely(!(flags & (TRACE_RECORD_CMDLINE | TRACE_RECORD_TGID)))) + return true; +- if (atomic_read(&trace_record_taskinfo_disabled) || !tracing_is_on()) +- return true; + if (!__this_cpu_read(trace_taskinfo_save)) + return true; + return false; diff --git a/queue-4.19/tracing-do-not-stop-recording-comms-if-the-trace-file-is-being-read.patch b/queue-4.19/tracing-do-not-stop-recording-comms-if-the-trace-file-is-being-read.patch new file mode 100644 index 00000000000..f85239fe136 --- /dev/null +++ b/queue-4.19/tracing-do-not-stop-recording-comms-if-the-trace-file-is-being-read.patch @@ -0,0 +1,56 @@ +From 4fdd595e4f9a1ff6d93ec702eaecae451cfc6591 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (VMware)" +Date: Thu, 17 Jun 2021 14:32:34 -0400 +Subject: tracing: Do not stop recording comms if the trace file is being read + +From: Steven Rostedt (VMware) + +commit 4fdd595e4f9a1ff6d93ec702eaecae451cfc6591 upstream. + +A while ago, when the "trace" file was opened, tracing was stopped, and +code was added to stop recording the comms to saved_cmdlines, for mapping +of the pids to the task name. + +Code has been added that only records the comm if a trace event occurred, +and there's no reason to not trace it if the trace file is opened. + +Cc: stable@vger.kernel.org +Fixes: 7ffbd48d5cab2 ("tracing: Cache comms only after an event occurred") +Signed-off-by: Steven Rostedt (VMware) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace.c | 9 --------- + 1 file changed, 9 deletions(-) + +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -1743,9 +1743,6 @@ struct saved_cmdlines_buffer { + }; + static struct saved_cmdlines_buffer *savedcmd; + +-/* temporary disable recording */ +-static atomic_t trace_record_taskinfo_disabled __read_mostly; +- + static inline char *get_saved_cmdlines(int idx) + { + return &savedcmd->saved_cmdlines[idx * TASK_COMM_LEN]; +@@ -3259,9 +3256,6 @@ static void *s_start(struct seq_file *m, + return ERR_PTR(-EBUSY); + #endif + +- if (!iter->snapshot) +- atomic_inc(&trace_record_taskinfo_disabled); +- + if (*pos != iter->pos) { + iter->ent = NULL; + iter->cpu = 0; +@@ -3304,9 +3298,6 @@ static void s_stop(struct seq_file *m, v + return; + #endif + +- if (!iter->snapshot) +- atomic_dec(&trace_record_taskinfo_disabled); +- + trace_access_unlock(iter->cpu_file); + trace_event_read_unlock(); + } diff --git a/queue-4.19/usb-core-hub-disable-autosuspend-for-cypress-cy7c65632.patch b/queue-4.19/usb-core-hub-disable-autosuspend-for-cypress-cy7c65632.patch new file mode 100644 index 00000000000..b7bfe148cd3 --- /dev/null +++ b/queue-4.19/usb-core-hub-disable-autosuspend-for-cypress-cy7c65632.patch @@ -0,0 +1,50 @@ +From a7d8d1c7a7f73e780aa9ae74926ae5985b2f895f Mon Sep 17 00:00:00 2001 +From: Andrew Lunn +Date: Mon, 14 Jun 2021 17:55:23 +0200 +Subject: usb: core: hub: Disable autosuspend for Cypress CY7C65632 + +From: Andrew Lunn + +commit a7d8d1c7a7f73e780aa9ae74926ae5985b2f895f upstream. + +The Cypress CY7C65632 appears to have an issue with auto suspend and +detecting devices, not too dissimilar to the SMSC 5534B hub. It is +easiest to reproduce by connecting multiple mass storage devices to +the hub at the same time. On a Lenovo Yoga, around 1 in 3 attempts +result in the devices not being detected. It is however possible to +make them appear using lsusb -v. + +Disabling autosuspend for this hub resolves the issue. + +Fixes: 1208f9e1d758 ("USB: hub: Fix the broken detection of USB3 device in SMSC hub") +Cc: stable@vger.kernel.org +Signed-off-by: Andrew Lunn +Link: https://lore.kernel.org/r/20210614155524.2228800-1-andrew@lunn.ch +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/core/hub.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/drivers/usb/core/hub.c ++++ b/drivers/usb/core/hub.c +@@ -38,6 +38,8 @@ + #define USB_VENDOR_GENESYS_LOGIC 0x05e3 + #define USB_VENDOR_SMSC 0x0424 + #define USB_PRODUCT_USB5534B 0x5534 ++#define USB_VENDOR_CYPRESS 0x04b4 ++#define USB_PRODUCT_CY7C65632 0x6570 + #define HUB_QUIRK_CHECK_PORT_AUTOSUSPEND 0x01 + #define HUB_QUIRK_DISABLE_AUTOSUSPEND 0x02 + +@@ -5443,6 +5445,11 @@ static const struct usb_device_id hub_id + .bInterfaceClass = USB_CLASS_HUB, + .driver_info = HUB_QUIRK_DISABLE_AUTOSUSPEND}, + { .match_flags = USB_DEVICE_ID_MATCH_VENDOR ++ | USB_DEVICE_ID_MATCH_PRODUCT, ++ .idVendor = USB_VENDOR_CYPRESS, ++ .idProduct = USB_PRODUCT_CY7C65632, ++ .driver_info = HUB_QUIRK_DISABLE_AUTOSUSPEND}, ++ { .match_flags = USB_DEVICE_ID_MATCH_VENDOR + | USB_DEVICE_ID_MATCH_INT_CLASS, + .idVendor = USB_VENDOR_GENESYS_LOGIC, + .bInterfaceClass = USB_CLASS_HUB,