From: Greg Kroah-Hartman Date: Mon, 11 Feb 2019 11:39:18 +0000 (+0100) Subject: 4.9-stable patches X-Git-Tag: v4.9.156~24 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=c8b255269b4213c8c8b9b88476e1aa7c53a08195;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: dmaengine-bcm2835-fix-abort-of-transactions.patch dmaengine-bcm2835-fix-interrupt-race-on-rt.patch dmaengine-imx-dma-fix-wrong-callback-invoke.patch kvm-fix-kvm_ioctl_create_device-reference-counting-cve-2019-6974.patch kvm-nvmx-unconditionally-cancel-preemption-timer-in-free_nested-cve-2019-7221.patch kvm-x86-work-around-leak-of-uninitialized-stack-contents-cve-2019-7222.patch perf-core-don-t-warn-for-impossible-ring-buffer-sizes.patch perf-tests-evsel-tp-sched-fix-bitwise-operator.patch perf-x86-intel-uncore-add-node-id-mask.patch scsi-aic94xx-fix-module-loading.patch serial-fix-race-between-flush_to_ldisc-and-tty_open.patch usb-gadget-musb-fix-short-isoc-packets-with-inventra-dma.patch usb-gadget-udc-net2272-fix-bitwise-and-boolean-operations.patch usb-phy-am335x-fix-race-condition-in-_probe.patch x86-mce-initialize-mce.bank-in-the-case-of-a-fatal-error-in-mce_no_way_out.patch --- diff --git a/queue-4.9/dmaengine-bcm2835-fix-abort-of-transactions.patch b/queue-4.9/dmaengine-bcm2835-fix-abort-of-transactions.patch new file mode 100644 index 00000000000..130511bec62 --- /dev/null +++ b/queue-4.9/dmaengine-bcm2835-fix-abort-of-transactions.patch @@ -0,0 +1,162 @@ +From 9e528c799d17a4ac37d788c81440b50377dd592d Mon Sep 17 00:00:00 2001 +From: Lukas Wunner +Date: Wed, 23 Jan 2019 09:26:00 +0100 +Subject: dmaengine: bcm2835: Fix abort of transactions + +From: Lukas Wunner + +commit 9e528c799d17a4ac37d788c81440b50377dd592d upstream. + +There are multiple issues with bcm2835_dma_abort() (which is called on +termination of a transaction): + +* The algorithm to abort the transaction first pauses the channel by + clearing the ACTIVE flag in the CS register, then waits for the PAUSED + flag to clear. Page 49 of the spec documents the latter as follows: + + "Indicates if the DMA is currently paused and not transferring data. + This will occur if the active bit has been cleared [...]" + https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf + + So the function is entering an infinite loop because it is waiting for + PAUSED to clear which is always set due to the function having cleared + the ACTIVE flag. The only thing that's saving it from itself is the + upper bound of 10000 loop iterations. + + The code comment says that the intention is to "wait for any current + AXI transfer to complete", so the author probably wanted to check the + WAITING_FOR_OUTSTANDING_WRITES flag instead. Amend the function + accordingly. + +* The CS register is only read at the beginning of the function. It + needs to be read again after pausing the channel and before checking + for outstanding writes, otherwise writes which were issued between + the register read at the beginning of the function and pausing the + channel may not be waited for. + +* The function seeks to abort the transfer by writing 0 to the NEXTCONBK + register and setting the ABORT and ACTIVE flags. Thereby, the 0 in + NEXTCONBK is sought to be loaded into the CONBLK_AD register. However + experimentation has shown this approach to not work: The CONBLK_AD + register remains the same as before and the CS register contains + 0x00000030 (PAUSED | DREQ_STOPS_DMA). In other words, the control + block is not aborted but merely paused and it will be resumed once the + next DMA transaction is started. That is absolutely not the desired + behavior. + + A simpler approach is to set the channel's RESET flag instead. This + reliably zeroes the NEXTCONBK as well as the CS register. It requires + less code and only a single MMIO write. This is also what popular + user space DMA drivers do, e.g.: + https://github.com/metachris/RPIO/blob/master/source/c_pwm/pwm.c + + Note that the spec is contradictory whether the NEXTCONBK register + is writeable at all. On the one hand, page 41 claims: + + "The value loaded into the NEXTCONBK register can be overwritten so + that the linked list of Control Block data structures can be + dynamically altered. However it is only safe to do this when the DMA + is paused." + + On the other hand, page 40 specifies: + + "Only three registers in each channel's register set are directly + writeable (CS, CONBLK_AD and DEBUG). The other registers (TI, + SOURCE_AD, DEST_AD, TXFR_LEN, STRIDE & NEXTCONBK), are automatically + loaded from a Control Block data structure held in external memory." + +Fixes: 96286b576690 ("dmaengine: Add support for BCM2835") +Signed-off-by: Lukas Wunner +Cc: stable@vger.kernel.org # v3.14+ +Cc: Frank Pavlic +Cc: Martin Sperl +Cc: Florian Meier +Cc: Clive Messer +Cc: Matthias Reichl +Tested-by: Stefan Wahren +Acked-by: Florian Kauer +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/dma/bcm2835-dma.c | 41 +++++++++-------------------------------- + 1 file changed, 9 insertions(+), 32 deletions(-) + +--- a/drivers/dma/bcm2835-dma.c ++++ b/drivers/dma/bcm2835-dma.c +@@ -415,13 +415,11 @@ static void bcm2835_dma_fill_cb_chain_wi + } + } + +-static int bcm2835_dma_abort(void __iomem *chan_base) ++static int bcm2835_dma_abort(struct bcm2835_chan *c) + { +- unsigned long cs; ++ void __iomem *chan_base = c->chan_base; + long int timeout = 10000; + +- cs = readl(chan_base + BCM2835_DMA_CS); +- + /* + * A zero control block address means the channel is idle. + * (The ACTIVE flag in the CS register is not a reliable indicator.) +@@ -433,25 +431,16 @@ static int bcm2835_dma_abort(void __iome + writel(0, chan_base + BCM2835_DMA_CS); + + /* Wait for any current AXI transfer to complete */ +- while ((cs & BCM2835_DMA_ISPAUSED) && --timeout) { ++ while ((readl(chan_base + BCM2835_DMA_CS) & ++ BCM2835_DMA_WAITING_FOR_WRITES) && --timeout) + cpu_relax(); +- cs = readl(chan_base + BCM2835_DMA_CS); +- } + +- /* We'll un-pause when we set of our next DMA */ ++ /* Peripheral might be stuck and fail to signal AXI write responses */ + if (!timeout) +- return -ETIMEDOUT; +- +- if (!(cs & BCM2835_DMA_ACTIVE)) +- return 0; +- +- /* Terminate the control block chain */ +- writel(0, chan_base + BCM2835_DMA_NEXTCB); +- +- /* Abort the whole DMA */ +- writel(BCM2835_DMA_ABORT | BCM2835_DMA_ACTIVE, +- chan_base + BCM2835_DMA_CS); ++ dev_err(c->vc.chan.device->dev, ++ "failed to complete outstanding writes\n"); + ++ writel(BCM2835_DMA_RESET, chan_base + BCM2835_DMA_CS); + return 0; + } + +@@ -804,7 +793,6 @@ static int bcm2835_dma_terminate_all(str + struct bcm2835_chan *c = to_bcm2835_dma_chan(chan); + struct bcm2835_dmadev *d = to_bcm2835_dma_dev(c->vc.chan.device); + unsigned long flags; +- int timeout = 10000; + LIST_HEAD(head); + + spin_lock_irqsave(&c->vc.lock, flags); +@@ -818,18 +806,7 @@ static int bcm2835_dma_terminate_all(str + if (c->desc) { + bcm2835_dma_desc_free(&c->desc->vd); + c->desc = NULL; +- bcm2835_dma_abort(c->chan_base); +- +- /* Wait for stopping */ +- while (--timeout) { +- if (!readl(c->chan_base + BCM2835_DMA_ADDR)) +- break; +- +- cpu_relax(); +- } +- +- if (!timeout) +- dev_err(d->ddev.dev, "DMA transfer could not be terminated\n"); ++ bcm2835_dma_abort(c); + } + + vchan_get_all_descriptors(&c->vc, &head); diff --git a/queue-4.9/dmaengine-bcm2835-fix-interrupt-race-on-rt.patch b/queue-4.9/dmaengine-bcm2835-fix-interrupt-race-on-rt.patch new file mode 100644 index 00000000000..3954696bbc4 --- /dev/null +++ b/queue-4.9/dmaengine-bcm2835-fix-interrupt-race-on-rt.patch @@ -0,0 +1,155 @@ +From f7da7782aba92593f7b82f03d2409a1c5f4db91b Mon Sep 17 00:00:00 2001 +From: Lukas Wunner +Date: Wed, 23 Jan 2019 09:26:00 +0100 +Subject: dmaengine: bcm2835: Fix interrupt race on RT + +From: Lukas Wunner + +commit f7da7782aba92593f7b82f03d2409a1c5f4db91b upstream. + +If IRQ handlers are threaded (either because CONFIG_PREEMPT_RT_BASE is +enabled or "threadirqs" was passed on the command line) and if system +load is sufficiently high that wakeup latency of IRQ threads degrades, +SPI DMA transactions on the BCM2835 occasionally break like this: + +ks8851 spi0.0: SPI transfer timed out +bcm2835-dma 3f007000.dma: DMA transfer could not be terminated +ks8851 spi0.0 eth2: ks8851_rdfifo: spi_sync() failed + +The root cause is an assumption made by the DMA driver which is +documented in a code comment in bcm2835_dma_terminate_all(): + +/* + * Stop DMA activity: we assume the callback will not be called + * after bcm_dma_abort() returns (even if it does, it will see + * c->desc is NULL and exit.) + */ + +That assumption falls apart if the IRQ handler bcm2835_dma_callback() is +threaded: A client may terminate a descriptor and issue a new one +before the IRQ handler had a chance to run. In fact the IRQ handler may +miss an *arbitrary* number of descriptors. The result is the following +race condition: + +1. A descriptor finishes, its interrupt is deferred to the IRQ thread. +2. A client calls dma_terminate_async() which sets channel->desc = NULL. +3. The client issues a new descriptor. Because channel->desc is NULL, + bcm2835_dma_issue_pending() immediately starts the descriptor. +4. Finally the IRQ thread runs and writes BCM2835_DMA_INT to the CS + register to acknowledge the interrupt. This clears the ACTIVE flag, + so the newly issued descriptor is paused in the middle of the + transaction. Because channel->desc is not NULL, the IRQ thread + finalizes the descriptor and tries to start the next one. + +I see two possible solutions: The first is to call synchronize_irq() +in bcm2835_dma_issue_pending() to wait until the IRQ thread has +finished before issuing a new descriptor. The downside of this approach +is unnecessary latency if clients desire rapidly terminating and +re-issuing descriptors and don't have any use for an IRQ callback. +(The SPI TX DMA channel is a case in point.) + +A better alternative is to make the IRQ thread recognize that it has +missed descriptors and avoid finalizing the newly issued descriptor. +So first of all, set the ACTIVE flag when acknowledging the interrupt. +This keeps a newly issued descriptor running. + +If the descriptor was finished, the channel remains idle despite the +ACTIVE flag being set. However the ACTIVE flag can then no longer be +used to check whether the channel is idle, so instead check whether +the register containing the current control block address is zero +and finalize the current descriptor only if so. + +That way, there is no impact on latency and throughput if the client +doesn't care for the interrupt: Only minimal additional overhead is +introduced for non-cyclic descriptors as one further MMIO read is +necessary per interrupt to check for idleness of the channel. Cyclic +descriptors are sped up slightly by removing one MMIO write per +interrupt. + +Fixes: 96286b576690 ("dmaengine: Add support for BCM2835") +Signed-off-by: Lukas Wunner +Cc: stable@vger.kernel.org # v3.14+ +Cc: Frank Pavlic +Cc: Martin Sperl +Cc: Florian Meier +Cc: Clive Messer +Cc: Matthias Reichl +Tested-by: Stefan Wahren +Acked-by: Florian Kauer +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/dma/bcm2835-dma.c | 33 ++++++++++++++++++--------------- + 1 file changed, 18 insertions(+), 15 deletions(-) + +--- a/drivers/dma/bcm2835-dma.c ++++ b/drivers/dma/bcm2835-dma.c +@@ -421,7 +421,12 @@ static int bcm2835_dma_abort(void __iome + long int timeout = 10000; + + cs = readl(chan_base + BCM2835_DMA_CS); +- if (!(cs & BCM2835_DMA_ACTIVE)) ++ ++ /* ++ * A zero control block address means the channel is idle. ++ * (The ACTIVE flag in the CS register is not a reliable indicator.) ++ */ ++ if (!readl(chan_base + BCM2835_DMA_ADDR)) + return 0; + + /* Write 0 to the active bit - Pause the DMA */ +@@ -485,8 +490,15 @@ static irqreturn_t bcm2835_dma_callback( + + spin_lock_irqsave(&c->vc.lock, flags); + +- /* Acknowledge interrupt */ +- writel(BCM2835_DMA_INT, c->chan_base + BCM2835_DMA_CS); ++ /* ++ * Clear the INT flag to receive further interrupts. Keep the channel ++ * active in case the descriptor is cyclic or in case the client has ++ * already terminated the descriptor and issued a new one. (May happen ++ * if this IRQ handler is threaded.) If the channel is finished, it ++ * will remain idle despite the ACTIVE flag being set. ++ */ ++ writel(BCM2835_DMA_INT | BCM2835_DMA_ACTIVE, ++ c->chan_base + BCM2835_DMA_CS); + + d = c->desc; + +@@ -494,11 +506,7 @@ static irqreturn_t bcm2835_dma_callback( + if (d->cyclic) { + /* call the cyclic callback */ + vchan_cyclic_callback(&d->vd); +- +- /* Keep the DMA engine running */ +- writel(BCM2835_DMA_ACTIVE, +- c->chan_base + BCM2835_DMA_CS); +- } else { ++ } else if (!readl(c->chan_base + BCM2835_DMA_ADDR)) { + vchan_cookie_complete(&c->desc->vd); + bcm2835_dma_start_desc(c); + } +@@ -806,11 +814,7 @@ static int bcm2835_dma_terminate_all(str + list_del_init(&c->node); + spin_unlock(&d->lock); + +- /* +- * Stop DMA activity: we assume the callback will not be called +- * after bcm_dma_abort() returns (even if it does, it will see +- * c->desc is NULL and exit.) +- */ ++ /* stop DMA activity */ + if (c->desc) { + bcm2835_dma_desc_free(&c->desc->vd); + c->desc = NULL; +@@ -818,8 +822,7 @@ static int bcm2835_dma_terminate_all(str + + /* Wait for stopping */ + while (--timeout) { +- if (!(readl(c->chan_base + BCM2835_DMA_CS) & +- BCM2835_DMA_ACTIVE)) ++ if (!readl(c->chan_base + BCM2835_DMA_ADDR)) + break; + + cpu_relax(); diff --git a/queue-4.9/dmaengine-imx-dma-fix-wrong-callback-invoke.patch b/queue-4.9/dmaengine-imx-dma-fix-wrong-callback-invoke.patch new file mode 100644 index 00000000000..3b2a6d740b9 --- /dev/null +++ b/queue-4.9/dmaengine-imx-dma-fix-wrong-callback-invoke.patch @@ -0,0 +1,64 @@ +From 341198eda723c8c1cddbb006a89ad9e362502ea2 Mon Sep 17 00:00:00 2001 +From: Leonid Iziumtsev +Date: Tue, 15 Jan 2019 17:15:23 +0000 +Subject: dmaengine: imx-dma: fix wrong callback invoke + +From: Leonid Iziumtsev + +commit 341198eda723c8c1cddbb006a89ad9e362502ea2 upstream. + +Once the "ld_queue" list is not empty, next descriptor will migrate +into "ld_active" list. The "desc" variable will be overwritten +during that transition. And later the dmaengine_desc_get_callback_invoke() +will use it as an argument. As result we invoke wrong callback. + +That behaviour was in place since: +commit fcaaba6c7136 ("dmaengine: imx-dma: fix callback path in tasklet"). +But after commit 4cd13c21b207 ("softirq: Let ksoftirqd do its job") +things got worse, since possible delay between tasklet_schedule() +from DMA irq handler and actual tasklet function execution got bigger. +And that gave more time for new DMA request to be submitted and +to be put into "ld_queue" list. + +It has been noticed that DMA issue is causing problems for "mxc-mmc" +driver. While stressing the system with heavy network traffic and +writing/reading to/from sd card simultaneously the timeout may happen: + +10013000.sdhci: mxcmci_watchdog: read time out (status = 0x30004900) + +That often lead to file system corruption. + +Signed-off-by: Leonid Iziumtsev +Signed-off-by: Vinod Koul +Cc: stable@vger.kernel.org +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/dma/imx-dma.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/dma/imx-dma.c ++++ b/drivers/dma/imx-dma.c +@@ -623,7 +623,7 @@ static void imxdma_tasklet(unsigned long + { + struct imxdma_channel *imxdmac = (void *)data; + struct imxdma_engine *imxdma = imxdmac->imxdma; +- struct imxdma_desc *desc; ++ struct imxdma_desc *desc, *next_desc; + unsigned long flags; + + spin_lock_irqsave(&imxdma->lock, flags); +@@ -653,10 +653,10 @@ static void imxdma_tasklet(unsigned long + list_move_tail(imxdmac->ld_active.next, &imxdmac->ld_free); + + if (!list_empty(&imxdmac->ld_queue)) { +- desc = list_first_entry(&imxdmac->ld_queue, struct imxdma_desc, +- node); ++ next_desc = list_first_entry(&imxdmac->ld_queue, ++ struct imxdma_desc, node); + list_move_tail(imxdmac->ld_queue.next, &imxdmac->ld_active); +- if (imxdma_xfer_desc(desc) < 0) ++ if (imxdma_xfer_desc(next_desc) < 0) + dev_warn(imxdma->dev, "%s: channel: %d couldn't xfer desc\n", + __func__, imxdmac->channel); + } diff --git a/queue-4.9/kvm-fix-kvm_ioctl_create_device-reference-counting-cve-2019-6974.patch b/queue-4.9/kvm-fix-kvm_ioctl_create_device-reference-counting-cve-2019-6974.patch new file mode 100644 index 00000000000..fd4127b7d23 --- /dev/null +++ b/queue-4.9/kvm-fix-kvm_ioctl_create_device-reference-counting-cve-2019-6974.patch @@ -0,0 +1,57 @@ +From cfa39381173d5f969daf43582c95ad679189cbc9 Mon Sep 17 00:00:00 2001 +From: Jann Horn +Date: Sat, 26 Jan 2019 01:54:33 +0100 +Subject: kvm: fix kvm_ioctl_create_device() reference counting (CVE-2019-6974) + +From: Jann Horn + +commit cfa39381173d5f969daf43582c95ad679189cbc9 upstream. + +kvm_ioctl_create_device() does the following: + +1. creates a device that holds a reference to the VM object (with a borrowed + reference, the VM's refcount has not been bumped yet) +2. initializes the device +3. transfers the reference to the device to the caller's file descriptor table +4. calls kvm_get_kvm() to turn the borrowed reference to the VM into a real + reference + +The ownership transfer in step 3 must not happen before the reference to the VM +becomes a proper, non-borrowed reference, which only happens in step 4. +After step 3, an attacker can close the file descriptor and drop the borrowed +reference, which can cause the refcount of the kvm object to drop to zero. + +This means that we need to grab a reference for the device before +anon_inode_getfd(), otherwise the VM can disappear from under us. + +Fixes: 852b6d57dc7f ("kvm: add device control API") +Cc: stable@kernel.org +Signed-off-by: Jann Horn +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + virt/kvm/kvm_main.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/virt/kvm/kvm_main.c ++++ b/virt/kvm/kvm_main.c +@@ -2900,8 +2900,10 @@ static int kvm_ioctl_create_device(struc + if (ops->init) + ops->init(dev); + ++ kvm_get_kvm(kvm); + ret = anon_inode_getfd(ops->name, &kvm_device_fops, dev, O_RDWR | O_CLOEXEC); + if (ret < 0) { ++ kvm_put_kvm(kvm); + mutex_lock(&kvm->lock); + list_del(&dev->vm_node); + mutex_unlock(&kvm->lock); +@@ -2909,7 +2911,6 @@ static int kvm_ioctl_create_device(struc + return ret; + } + +- kvm_get_kvm(kvm); + cd->fd = ret; + return 0; + } diff --git a/queue-4.9/kvm-nvmx-unconditionally-cancel-preemption-timer-in-free_nested-cve-2019-7221.patch b/queue-4.9/kvm-nvmx-unconditionally-cancel-preemption-timer-in-free_nested-cve-2019-7221.patch new file mode 100644 index 00000000000..152fe1d1df8 --- /dev/null +++ b/queue-4.9/kvm-nvmx-unconditionally-cancel-preemption-timer-in-free_nested-cve-2019-7221.patch @@ -0,0 +1,41 @@ +From ecec76885bcfe3294685dc363fd1273df0d5d65f Mon Sep 17 00:00:00 2001 +From: Peter Shier +Date: Thu, 11 Oct 2018 11:46:46 -0700 +Subject: KVM: nVMX: unconditionally cancel preemption timer in free_nested (CVE-2019-7221) + +From: Peter Shier + +commit ecec76885bcfe3294685dc363fd1273df0d5d65f upstream. + +Bugzilla: 1671904 + +There are multiple code paths where an hrtimer may have been started to +emulate an L1 VMX preemption timer that can result in a call to free_nested +without an intervening L2 exit where the hrtimer is normally +cancelled. Unconditionally cancel in free_nested to cover all cases. + +Embargoed until Feb 7th 2019. + +Signed-off-by: Peter Shier +Reported-by: Jim Mattson +Reviewed-by: Jim Mattson +Reported-by: Felix Wilhelm +Cc: stable@kernel.org +Message-Id: <20181011184646.154065-1-pshier@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/vmx.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/x86/kvm/vmx.c ++++ b/arch/x86/kvm/vmx.c +@@ -7368,6 +7368,7 @@ static void free_nested(struct vcpu_vmx + if (!vmx->nested.vmxon) + return; + ++ hrtimer_cancel(&vmx->nested.preemption_timer); + vmx->nested.vmxon = false; + free_vpid(vmx->nested.vpid02); + nested_release_vmcs12(vmx); diff --git a/queue-4.9/kvm-x86-work-around-leak-of-uninitialized-stack-contents-cve-2019-7222.patch b/queue-4.9/kvm-x86-work-around-leak-of-uninitialized-stack-contents-cve-2019-7222.patch new file mode 100644 index 00000000000..ac6ece538e8 --- /dev/null +++ b/queue-4.9/kvm-x86-work-around-leak-of-uninitialized-stack-contents-cve-2019-7222.patch @@ -0,0 +1,47 @@ +From 353c0956a618a07ba4bbe7ad00ff29fe70e8412a Mon Sep 17 00:00:00 2001 +From: Paolo Bonzini +Date: Tue, 29 Jan 2019 18:41:16 +0100 +Subject: KVM: x86: work around leak of uninitialized stack contents (CVE-2019-7222) + +From: Paolo Bonzini + +commit 353c0956a618a07ba4bbe7ad00ff29fe70e8412a upstream. + +Bugzilla: 1671930 + +Emulation of certain instructions (VMXON, VMCLEAR, VMPTRLD, VMWRITE with +memory operand, INVEPT, INVVPID) can incorrectly inject a page fault +when passed an operand that points to an MMIO address. The page fault +will use uninitialized kernel stack memory as the CR2 and error code. + +The right behavior would be to abort the VM with a KVM_EXIT_INTERNAL_ERROR +exit to userspace; however, it is not an easy fix, so for now just +ensure that the error code and CR2 are zero. + +Embargoed until Feb 7th 2019. + +Reported-by: Felix Wilhelm +Cc: stable@kernel.org +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kvm/x86.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -4513,6 +4513,13 @@ int kvm_read_guest_virt(struct kvm_vcpu + { + u32 access = (kvm_x86_ops->get_cpl(vcpu) == 3) ? PFERR_USER_MASK : 0; + ++ /* ++ * FIXME: this should call handle_emulation_failure if X86EMUL_IO_NEEDED ++ * is returned, but our callers are not ready for that and they blindly ++ * call kvm_inject_page_fault. Ensure that they at least do not leak ++ * uninitialized kernel stack memory into cr2 and error code. ++ */ ++ memset(exception, 0, sizeof(*exception)); + return kvm_read_guest_virt_helper(addr, val, bytes, vcpu, access, + exception); + } diff --git a/queue-4.9/perf-core-don-t-warn-for-impossible-ring-buffer-sizes.patch b/queue-4.9/perf-core-don-t-warn-for-impossible-ring-buffer-sizes.patch new file mode 100644 index 00000000000..4c88d06852c --- /dev/null +++ b/queue-4.9/perf-core-don-t-warn-for-impossible-ring-buffer-sizes.patch @@ -0,0 +1,55 @@ +From 9dff0aa95a324e262ffb03f425d00e4751f3294e Mon Sep 17 00:00:00 2001 +From: Mark Rutland +Date: Thu, 10 Jan 2019 14:27:45 +0000 +Subject: perf/core: Don't WARN() for impossible ring-buffer sizes + +From: Mark Rutland + +commit 9dff0aa95a324e262ffb03f425d00e4751f3294e upstream. + +The perf tool uses /proc/sys/kernel/perf_event_mlock_kb to determine how +large its ringbuffer mmap should be. This can be configured to arbitrary +values, which can be larger than the maximum possible allocation from +kmalloc. + +When this is configured to a suitably large value (e.g. thanks to the +perf fuzzer), attempting to use perf record triggers a WARN_ON_ONCE() in +__alloc_pages_nodemask(): + + WARNING: CPU: 2 PID: 5666 at mm/page_alloc.c:4511 __alloc_pages_nodemask+0x3f8/0xbc8 + +Let's avoid this by checking that the requested allocation is possible +before calling kzalloc. + +Reported-by: Julien Thierry +Signed-off-by: Mark Rutland +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Julien Thierry +Cc: Alexander Shishkin +Cc: Arnaldo Carvalho de Melo +Cc: Jiri Olsa +Cc: Linus Torvalds +Cc: Namhyung Kim +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: +Link: https://lkml.kernel.org/r/20190110142745.25495-1-mark.rutland@arm.com +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/events/ring_buffer.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/kernel/events/ring_buffer.c ++++ b/kernel/events/ring_buffer.c +@@ -700,6 +700,9 @@ struct ring_buffer *rb_alloc(int nr_page + size = sizeof(struct ring_buffer); + size += nr_pages * sizeof(void *); + ++ if (order_base_2(size) >= MAX_ORDER) ++ goto fail; ++ + rb = kzalloc(size, GFP_KERNEL); + if (!rb) + goto fail; diff --git a/queue-4.9/perf-tests-evsel-tp-sched-fix-bitwise-operator.patch b/queue-4.9/perf-tests-evsel-tp-sched-fix-bitwise-operator.patch new file mode 100644 index 00000000000..f0f96691915 --- /dev/null +++ b/queue-4.9/perf-tests-evsel-tp-sched-fix-bitwise-operator.patch @@ -0,0 +1,43 @@ +From 489338a717a0dfbbd5a3fabccf172b78f0ac9015 Mon Sep 17 00:00:00 2001 +From: "Gustavo A. R. Silva" +Date: Tue, 22 Jan 2019 17:34:39 -0600 +Subject: perf tests evsel-tp-sched: Fix bitwise operator + +From: Gustavo A. R. Silva + +commit 489338a717a0dfbbd5a3fabccf172b78f0ac9015 upstream. + +Notice that the use of the bitwise OR operator '|' always leads to true +in this particular case, which seems a bit suspicious due to the context +in which this expression is being used. + +Fix this by using bitwise AND operator '&' instead. + +This bug was detected with the help of Coccinelle. + +Signed-off-by: Gustavo A. R. Silva +Acked-by: Jiri Olsa +Cc: Alexander Shishkin +Cc: Namhyung Kim +Cc: Peter Zijlstra +Cc: stable@vger.kernel.org +Fixes: 6a6cd11d4e57 ("perf test: Add test for the sched tracepoint format fields") +Link: http://lkml.kernel.org/r/20190122233439.GA5868@embeddedor +Signed-off-by: Arnaldo Carvalho de Melo +Signed-off-by: Greg Kroah-Hartman + +--- + tools/perf/tests/evsel-tp-sched.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/tools/perf/tests/evsel-tp-sched.c ++++ b/tools/perf/tests/evsel-tp-sched.c +@@ -16,7 +16,7 @@ static int perf_evsel__test_field(struct + return -1; + } + +- is_signed = !!(field->flags | FIELD_IS_SIGNED); ++ is_signed = !!(field->flags & FIELD_IS_SIGNED); + if (should_be_signed && !is_signed) { + pr_debug("%s: \"%s\" signedness(%d) is wrong, should be %d\n", + evsel->name, name, is_signed, should_be_signed); diff --git a/queue-4.9/perf-x86-intel-uncore-add-node-id-mask.patch b/queue-4.9/perf-x86-intel-uncore-add-node-id-mask.patch new file mode 100644 index 00000000000..8c2b743bbd4 --- /dev/null +++ b/queue-4.9/perf-x86-intel-uncore-add-node-id-mask.patch @@ -0,0 +1,63 @@ +From 9e63a7894fd302082cf3627fe90844421a6cbe7f Mon Sep 17 00:00:00 2001 +From: Kan Liang +Date: Sun, 27 Jan 2019 06:53:14 -0800 +Subject: perf/x86/intel/uncore: Add Node ID mask + +From: Kan Liang + +commit 9e63a7894fd302082cf3627fe90844421a6cbe7f upstream. + +Some PCI uncore PMUs cannot be registered on an 8-socket system (HPE +Superdome Flex). + +To understand which Socket the PCI uncore PMUs belongs to, perf retrieves +the local Node ID of the uncore device from CPUNODEID(0xC0) of the PCI +configuration space, and the mapping between Socket ID and Node ID from +GIDNIDMAP(0xD4). The Socket ID can be calculated accordingly. + +The local Node ID is only available at bit 2:0, but current code doesn't +mask it. If a BIOS doesn't clear the rest of the bits, an incorrect Node ID +will be fetched. + +Filter the Node ID by adding a mask. + +Reported-by: Song Liu +Tested-by: Song Liu +Signed-off-by: Kan Liang +Signed-off-by: Peter Zijlstra (Intel) +Cc: Alexander Shishkin +Cc: Arnaldo Carvalho de Melo +Cc: Jiri Olsa +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: # v3.7+ +Fixes: 7c94ee2e0917 ("perf/x86: Add Intel Nehalem and Sandy Bridge-EP uncore support") +Link: https://lkml.kernel.org/r/1548600794-33162-1-git-send-email-kan.liang@linux.intel.com +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/events/intel/uncore_snbep.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/arch/x86/events/intel/uncore_snbep.c ++++ b/arch/x86/events/intel/uncore_snbep.c +@@ -1221,6 +1221,8 @@ static struct pci_driver snbep_uncore_pc + .id_table = snbep_uncore_pci_ids, + }; + ++#define NODE_ID_MASK 0x7 ++ + /* + * build pci bus to socket mapping + */ +@@ -1242,7 +1244,7 @@ static int snbep_pci2phy_map_init(int de + err = pci_read_config_dword(ubox_dev, nodeid_loc, &config); + if (err) + break; +- nodeid = config; ++ nodeid = config & NODE_ID_MASK; + /* get the Node ID mapping */ + err = pci_read_config_dword(ubox_dev, idmap_loc, &config); + if (err) diff --git a/queue-4.9/scsi-aic94xx-fix-module-loading.patch b/queue-4.9/scsi-aic94xx-fix-module-loading.patch new file mode 100644 index 00000000000..58dd575abbd --- /dev/null +++ b/queue-4.9/scsi-aic94xx-fix-module-loading.patch @@ -0,0 +1,65 @@ +From 42caa0edabd6a0a392ec36a5f0943924e4954311 Mon Sep 17 00:00:00 2001 +From: James Bottomley +Date: Wed, 30 Jan 2019 16:42:12 -0800 +Subject: scsi: aic94xx: fix module loading + +From: James Bottomley + +commit 42caa0edabd6a0a392ec36a5f0943924e4954311 upstream. + +The aic94xx driver is currently failing to load with errors like + +sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:03.0/0000:02:00.3/0000:07:02.0/revision' + +Because the PCI code had recently added a file named 'revision' to every +PCI device. Fix this by renaming the aic94xx revision file to +aic_revision. This is safe to do for us because as far as I can tell, +there's nothing in userspace relying on the current aic94xx revision file +so it can be renamed without breaking anything. + +Fixes: 702ed3be1b1b (PCI: Create revision file in sysfs) +Cc: stable@vger.kernel.org +Signed-off-by: James Bottomley +Signed-off-by: Martin K. Petersen +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/scsi/aic94xx/aic94xx_init.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/scsi/aic94xx/aic94xx_init.c ++++ b/drivers/scsi/aic94xx/aic94xx_init.c +@@ -281,7 +281,7 @@ static ssize_t asd_show_dev_rev(struct d + return snprintf(buf, PAGE_SIZE, "%s\n", + asd_dev_rev[asd_ha->revision_id]); + } +-static DEVICE_ATTR(revision, S_IRUGO, asd_show_dev_rev, NULL); ++static DEVICE_ATTR(aic_revision, S_IRUGO, asd_show_dev_rev, NULL); + + static ssize_t asd_show_dev_bios_build(struct device *dev, + struct device_attribute *attr,char *buf) +@@ -478,7 +478,7 @@ static int asd_create_dev_attrs(struct a + { + int err; + +- err = device_create_file(&asd_ha->pcidev->dev, &dev_attr_revision); ++ err = device_create_file(&asd_ha->pcidev->dev, &dev_attr_aic_revision); + if (err) + return err; + +@@ -500,13 +500,13 @@ err_update_bios: + err_biosb: + device_remove_file(&asd_ha->pcidev->dev, &dev_attr_bios_build); + err_rev: +- device_remove_file(&asd_ha->pcidev->dev, &dev_attr_revision); ++ device_remove_file(&asd_ha->pcidev->dev, &dev_attr_aic_revision); + return err; + } + + static void asd_remove_dev_attrs(struct asd_ha_struct *asd_ha) + { +- device_remove_file(&asd_ha->pcidev->dev, &dev_attr_revision); ++ device_remove_file(&asd_ha->pcidev->dev, &dev_attr_aic_revision); + device_remove_file(&asd_ha->pcidev->dev, &dev_attr_bios_build); + device_remove_file(&asd_ha->pcidev->dev, &dev_attr_pcba_sn); + device_remove_file(&asd_ha->pcidev->dev, &dev_attr_update_bios); diff --git a/queue-4.9/serial-fix-race-between-flush_to_ldisc-and-tty_open.patch b/queue-4.9/serial-fix-race-between-flush_to_ldisc-and-tty_open.patch new file mode 100644 index 00000000000..d6c771d1401 --- /dev/null +++ b/queue-4.9/serial-fix-race-between-flush_to_ldisc-and-tty_open.patch @@ -0,0 +1,84 @@ +From fedb5760648a291e949f2380d383b5b2d2749b5e Mon Sep 17 00:00:00 2001 +From: Greg Kroah-Hartman +Date: Thu, 31 Jan 2019 17:43:16 +0800 +Subject: serial: fix race between flush_to_ldisc and tty_open + +From: Greg Kroah-Hartman + +commit fedb5760648a291e949f2380d383b5b2d2749b5e upstream. + +There still is a race window after the commit b027e2298bd588 +("tty: fix data race between tty_init_dev and flush of buf"), +and we encountered this crash issue if receive_buf call comes +before tty initialization completes in tty_open and +tty->driver_data may be NULL. + +CPU0 CPU1 +---- ---- + tty_open + tty_init_dev + tty_ldisc_unlock + schedule +flush_to_ldisc + receive_buf + tty_port_default_receive_buf + tty_ldisc_receive_buf + n_tty_receive_buf_common + __receive_buf + uart_flush_chars + uart_start + /*tty->driver_data is NULL*/ + tty->ops->open + /*init tty->driver_data*/ + +it can be fixed by extending ldisc semaphore lock in tty_init_dev +to driver_data initialized completely after tty->ops->open(), but +this will lead to get lock on one function and unlock in some other +function, and hard to maintain, so fix this race only by checking +tty->driver_data when receiving, and return if tty->driver_data +is NULL, and n_tty_receive_buf_common maybe calls uart_unthrottle, +so add the same check. + +Because the tty layer knows nothing about the driver associated with the +device, the tty layer can not do anything here, it is up to the tty +driver itself to check for this type of race. Fix up the serial driver +to correctly check to see if it is finished binding with the device when +being called, and if not, abort the tty calls. + +[Description and problem report and testing from Li RongQing, I rewrote +the patch to be in the serial layer, not in the tty core - gregkh] + +Reported-by: Li RongQing +Tested-by: Li RongQing +Signed-off-by: Wang Li +Signed-off-by: Zhang Yu +Signed-off-by: Li RongQing +Cc: stable +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/tty/serial/serial_core.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/drivers/tty/serial/serial_core.c ++++ b/drivers/tty/serial/serial_core.c +@@ -141,6 +141,9 @@ static void uart_start(struct tty_struct + struct uart_port *port; + unsigned long flags; + ++ if (!state) ++ return; ++ + port = uart_port_lock(state, flags); + __uart_start(tty); + uart_port_unlock(port, flags); +@@ -717,6 +720,9 @@ static void uart_unthrottle(struct tty_s + struct uart_port *port; + upstat_t mask = 0; + ++ if (!state) ++ return; ++ + port = uart_port_ref(state); + if (!port) + return; diff --git a/queue-4.9/series b/queue-4.9/series index 00b8140b2c7..04e8a8f416c 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -116,3 +116,18 @@ alsa-hda-serialize-codec-registrations.patch fuse-call-pipe_buf_release-under-pipe-lock.patch fuse-decrement-nr_writeback_temp-on-the-right-page.patch fuse-handle-zero-sized-retrieve-correctly.patch +dmaengine-bcm2835-fix-interrupt-race-on-rt.patch +dmaengine-bcm2835-fix-abort-of-transactions.patch +dmaengine-imx-dma-fix-wrong-callback-invoke.patch +usb-phy-am335x-fix-race-condition-in-_probe.patch +usb-gadget-udc-net2272-fix-bitwise-and-boolean-operations.patch +usb-gadget-musb-fix-short-isoc-packets-with-inventra-dma.patch +scsi-aic94xx-fix-module-loading.patch +kvm-x86-work-around-leak-of-uninitialized-stack-contents-cve-2019-7222.patch +kvm-fix-kvm_ioctl_create_device-reference-counting-cve-2019-6974.patch +kvm-nvmx-unconditionally-cancel-preemption-timer-in-free_nested-cve-2019-7221.patch +perf-x86-intel-uncore-add-node-id-mask.patch +x86-mce-initialize-mce.bank-in-the-case-of-a-fatal-error-in-mce_no_way_out.patch +perf-core-don-t-warn-for-impossible-ring-buffer-sizes.patch +perf-tests-evsel-tp-sched-fix-bitwise-operator.patch +serial-fix-race-between-flush_to_ldisc-and-tty_open.patch diff --git a/queue-4.9/usb-gadget-musb-fix-short-isoc-packets-with-inventra-dma.patch b/queue-4.9/usb-gadget-musb-fix-short-isoc-packets-with-inventra-dma.patch new file mode 100644 index 00000000000..0e772c1310e --- /dev/null +++ b/queue-4.9/usb-gadget-musb-fix-short-isoc-packets-with-inventra-dma.patch @@ -0,0 +1,114 @@ +From c418fd6c01fbc5516a2cd1eaf1df1ec86869028a Mon Sep 17 00:00:00 2001 +From: Paul Elder +Date: Wed, 30 Jan 2019 08:13:21 -0600 +Subject: usb: gadget: musb: fix short isoc packets with inventra dma + +From: Paul Elder + +commit c418fd6c01fbc5516a2cd1eaf1df1ec86869028a upstream. + +Handling short packets (length < max packet size) in the Inventra DMA +engine in the MUSB driver causes the MUSB DMA controller to hang. An +example of a problem that is caused by this problem is when streaming +video out of a UVC gadget, only the first video frame is transferred. + +For short packets (mode-0 or mode-1 DMA), MUSB_TXCSR_TXPKTRDY must be +set manually by the driver. This was previously done in musb_g_tx +(musb_gadget.c), but incorrectly (all csr flags were cleared, and only +MUSB_TXCSR_MODE and MUSB_TXCSR_TXPKTRDY were set). Fixing that problem +allows some requests to be transferred correctly, but multiple requests +were often put together in one USB packet, and caused problems if the +packet size was not a multiple of 4. Instead, set MUSB_TXCSR_TXPKTRDY +in dma_controller_irq (musbhsdma.c), just like host mode transfers. + +This topic was originally tackled by Nicolas Boichat [0] [1] and is +discussed further at [2] as part of his GSoC project [3]. + +[0] https://groups.google.com/forum/?hl=en#!topic/beagleboard-gsoc/k8Azwfp75CU +[1] https://gitorious.org/beagleboard-usbsniffer/beagleboard-usbsniffer-kernel/commit/b0be3b6cc195ba732189b04f1d43ec843c3e54c9?p=beagleboard-usbsniffer:beagleboard-usbsniffer-kernel.git;a=patch;h=b0be3b6cc195ba732189b04f1d43ec843c3e54c9 +[2] http://beagleboard-usbsniffer.blogspot.com/2010/07/musb-isochronous-transfers-fixed.html +[3] http://elinux.org/BeagleBoard/GSoC/USBSniffer + +Fixes: 550a7375fe72 ("USB: Add MUSB and TUSB support") +Signed-off-by: Paul Elder +Signed-off-by: Bin Liu +Cc: stable +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/musb/musb_gadget.c | 13 +------------ + drivers/usb/musb/musbhsdma.c | 21 +++++++++++---------- + 2 files changed, 12 insertions(+), 22 deletions(-) + +--- a/drivers/usb/musb/musb_gadget.c ++++ b/drivers/usb/musb/musb_gadget.c +@@ -477,13 +477,10 @@ void musb_g_tx(struct musb *musb, u8 epn + } + + if (request) { +- u8 is_dma = 0; +- bool short_packet = false; + + trace_musb_req_tx(req); + + if (dma && (csr & MUSB_TXCSR_DMAENAB)) { +- is_dma = 1; + csr |= MUSB_TXCSR_P_WZC_BITS; + csr &= ~(MUSB_TXCSR_DMAENAB | MUSB_TXCSR_P_UNDERRUN | + MUSB_TXCSR_TXPKTRDY | MUSB_TXCSR_AUTOSET); +@@ -501,16 +498,8 @@ void musb_g_tx(struct musb *musb, u8 epn + */ + if ((request->zero && request->length) + && (request->length % musb_ep->packet_sz == 0) +- && (request->actual == request->length)) +- short_packet = true; ++ && (request->actual == request->length)) { + +- if ((musb_dma_inventra(musb) || musb_dma_ux500(musb)) && +- (is_dma && (!dma->desired_mode || +- (request->actual & +- (musb_ep->packet_sz - 1))))) +- short_packet = true; +- +- if (short_packet) { + /* + * On DMA completion, FIFO may not be + * available yet... +--- a/drivers/usb/musb/musbhsdma.c ++++ b/drivers/usb/musb/musbhsdma.c +@@ -320,12 +320,10 @@ static irqreturn_t dma_controller_irq(in + channel->status = MUSB_DMA_STATUS_FREE; + + /* completed */ +- if ((devctl & MUSB_DEVCTL_HM) +- && (musb_channel->transmit) +- && ((channel->desired_mode == 0) +- || (channel->actual_len & +- (musb_channel->max_packet_sz - 1))) +- ) { ++ if (musb_channel->transmit && ++ (!channel->desired_mode || ++ (channel->actual_len % ++ musb_channel->max_packet_sz))) { + u8 epnum = musb_channel->epnum; + int offset = musb->io.ep_offset(epnum, + MUSB_TXCSR); +@@ -337,11 +335,14 @@ static irqreturn_t dma_controller_irq(in + */ + musb_ep_select(mbase, epnum); + txcsr = musb_readw(mbase, offset); +- txcsr &= ~(MUSB_TXCSR_DMAENAB ++ if (channel->desired_mode == 1) { ++ txcsr &= ~(MUSB_TXCSR_DMAENAB + | MUSB_TXCSR_AUTOSET); +- musb_writew(mbase, offset, txcsr); +- /* Send out the packet */ +- txcsr &= ~MUSB_TXCSR_DMAMODE; ++ musb_writew(mbase, offset, txcsr); ++ /* Send out the packet */ ++ txcsr &= ~MUSB_TXCSR_DMAMODE; ++ txcsr |= MUSB_TXCSR_DMAENAB; ++ } + txcsr |= MUSB_TXCSR_TXPKTRDY; + musb_writew(mbase, offset, txcsr); + } diff --git a/queue-4.9/usb-gadget-udc-net2272-fix-bitwise-and-boolean-operations.patch b/queue-4.9/usb-gadget-udc-net2272-fix-bitwise-and-boolean-operations.patch new file mode 100644 index 00000000000..2f529e59bd1 --- /dev/null +++ b/queue-4.9/usb-gadget-udc-net2272-fix-bitwise-and-boolean-operations.patch @@ -0,0 +1,43 @@ +From 07c69f1148da7de3978686d3af9263325d9d60bd Mon Sep 17 00:00:00 2001 +From: "Gustavo A. R. Silva" +Date: Tue, 22 Jan 2019 15:28:08 -0600 +Subject: usb: gadget: udc: net2272: Fix bitwise and boolean operations + +From: Gustavo A. R. Silva + +commit 07c69f1148da7de3978686d3af9263325d9d60bd upstream. + +(!x & y) strikes again. + +Fix bitwise and boolean operations by enclosing the expression: + + intcsr & (1 << NET2272_PCI_IRQ) + +in parentheses, before applying the boolean operator '!'. + +Notice that this code has been there since 2011. So, it would +be helpful if someone can double-check this. + +This issue was detected with the help of Coccinelle. + +Fixes: ceb80363b2ec ("USB: net2272: driver for PLX NET2272 USB device controller") +Cc: stable@vger.kernel.org +Signed-off-by: Gustavo A. R. Silva +Signed-off-by: Felipe Balbi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/gadget/udc/net2272.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/usb/gadget/udc/net2272.c ++++ b/drivers/usb/gadget/udc/net2272.c +@@ -2096,7 +2096,7 @@ static irqreturn_t net2272_irq(int irq, + #if defined(PLX_PCI_RDK2) + /* see if PCI int for us by checking irqstat */ + intcsr = readl(dev->rdk2.fpga_base_addr + RDK2_IRQSTAT); +- if (!intcsr & (1 << NET2272_PCI_IRQ)) { ++ if (!(intcsr & (1 << NET2272_PCI_IRQ))) { + spin_unlock(&dev->lock); + return IRQ_NONE; + } diff --git a/queue-4.9/usb-phy-am335x-fix-race-condition-in-_probe.patch b/queue-4.9/usb-phy-am335x-fix-race-condition-in-_probe.patch new file mode 100644 index 00000000000..4de80365460 --- /dev/null +++ b/queue-4.9/usb-phy-am335x-fix-race-condition-in-_probe.patch @@ -0,0 +1,45 @@ +From a53469a68eb886e84dd8b69a1458a623d3591793 Mon Sep 17 00:00:00 2001 +From: Bin Liu +Date: Wed, 16 Jan 2019 11:54:07 -0600 +Subject: usb: phy: am335x: fix race condition in _probe + +From: Bin Liu + +commit a53469a68eb886e84dd8b69a1458a623d3591793 upstream. + +power off the phy should be done before populate the phy. Otherwise, +am335x_init() could be called by the phy owner to power on the phy first, +then am335x_phy_probe() turns off the phy again without the caller knowing +it. + +Fixes: 2fc711d76352 ("usb: phy: am335x: Enable USB remote wakeup using PHY wakeup") +Cc: stable@vger.kernel.org # v3.18+ +Signed-off-by: Bin Liu +Signed-off-by: Felipe Balbi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/phy/phy-am335x.c | 5 +---- + 1 file changed, 1 insertion(+), 4 deletions(-) + +--- a/drivers/usb/phy/phy-am335x.c ++++ b/drivers/usb/phy/phy-am335x.c +@@ -60,9 +60,6 @@ static int am335x_phy_probe(struct platf + if (ret) + return ret; + +- ret = usb_add_phy_dev(&am_phy->usb_phy_gen.phy); +- if (ret) +- return ret; + am_phy->usb_phy_gen.phy.init = am335x_init; + am_phy->usb_phy_gen.phy.shutdown = am335x_shutdown; + +@@ -81,7 +78,7 @@ static int am335x_phy_probe(struct platf + device_set_wakeup_enable(dev, false); + phy_ctrl_power(am_phy->phy_ctrl, am_phy->id, am_phy->dr_mode, false); + +- return 0; ++ return usb_add_phy_dev(&am_phy->usb_phy_gen.phy); + } + + static int am335x_phy_remove(struct platform_device *pdev) diff --git a/queue-4.9/x86-mce-initialize-mce.bank-in-the-case-of-a-fatal-error-in-mce_no_way_out.patch b/queue-4.9/x86-mce-initialize-mce.bank-in-the-case-of-a-fatal-error-in-mce_no_way_out.patch new file mode 100644 index 00000000000..825c930e748 --- /dev/null +++ b/queue-4.9/x86-mce-initialize-mce.bank-in-the-case-of-a-fatal-error-in-mce_no_way_out.patch @@ -0,0 +1,51 @@ +From d28af26faa0b1daf3c692603d46bc4687c16f19e Mon Sep 17 00:00:00 2001 +From: Tony Luck +Date: Thu, 31 Jan 2019 16:33:41 -0800 +Subject: x86/MCE: Initialize mce.bank in the case of a fatal error in mce_no_way_out() + +From: Tony Luck + +commit d28af26faa0b1daf3c692603d46bc4687c16f19e upstream. + +Internal injection testing crashed with a console log that said: + + mce: [Hardware Error]: CPU 7: Machine Check Exception: f Bank 0: bd80000000100134 + +This caused a lot of head scratching because the MCACOD (bits 15:0) of +that status is a signature from an L1 data cache error. But Linux says +that it found it in "Bank 0", which on this model CPU only reports L1 +instruction cache errors. + +The answer was that Linux doesn't initialize "m->bank" in the case that +it finds a fatal error in the mce_no_way_out() pre-scan of banks. If +this was a local machine check, then this partially initialized struct +mce is being passed to mce_panic(). + +Fix is simple: just initialize m->bank in the case of a fatal error. + +Fixes: 40c36e2741d7 ("x86/mce: Fix incorrect "Machine check from unknown source" message") +Signed-off-by: Tony Luck +Signed-off-by: Borislav Petkov +Cc: "H. Peter Anvin" +Cc: Ingo Molnar +Cc: Thomas Gleixner +Cc: Vishal Verma +Cc: x86-ml +Cc: stable@vger.kernel.org # v4.18 Note pre-v5.0 arch/x86/kernel/cpu/mce/core.c was called arch/x86/kernel/cpu/mcheck/mce.c +Link: https://lkml.kernel.org/r/20190201003341.10638-1-tony.luck@intel.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/mcheck/mce.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/x86/kernel/cpu/mcheck/mce.c ++++ b/arch/x86/kernel/cpu/mcheck/mce.c +@@ -751,6 +751,7 @@ static int mce_no_way_out(struct mce *m, + quirk_no_way_out(i, m, regs); + + if (mce_severity(m, mca_cfg.tolerant, &tmp, true) >= MCE_PANIC_SEVERITY) { ++ m->bank = i; + mce_read_aux(m, i); + *msg = tmp; + return 1;