--- /dev/null
+From 9e528c799d17a4ac37d788c81440b50377dd592d Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Wed, 23 Jan 2019 09:26:00 +0100
+Subject: dmaengine: bcm2835: Fix abort of transactions
+
+From: Lukas Wunner <lukas@wunner.de>
+
+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 <lukas@wunner.de>
+Cc: stable@vger.kernel.org # v3.14+
+Cc: Frank Pavlic <f.pavlic@kunbus.de>
+Cc: Martin Sperl <kernel@martin.sperl.org>
+Cc: Florian Meier <florian.meier@koalo.de>
+Cc: Clive Messer <clive.m.messer@gmail.com>
+Cc: Matthias Reichl <hias@horus.com>
+Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
+Acked-by: Florian Kauer <florian.kauer@koalo.de>
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From f7da7782aba92593f7b82f03d2409a1c5f4db91b Mon Sep 17 00:00:00 2001
+From: Lukas Wunner <lukas@wunner.de>
+Date: Wed, 23 Jan 2019 09:26:00 +0100
+Subject: dmaengine: bcm2835: Fix interrupt race on RT
+
+From: Lukas Wunner <lukas@wunner.de>
+
+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 <lukas@wunner.de>
+Cc: stable@vger.kernel.org # v3.14+
+Cc: Frank Pavlic <f.pavlic@kunbus.de>
+Cc: Martin Sperl <kernel@martin.sperl.org>
+Cc: Florian Meier <florian.meier@koalo.de>
+Cc: Clive Messer <clive.m.messer@gmail.com>
+Cc: Matthias Reichl <hias@horus.com>
+Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
+Acked-by: Florian Kauer <florian.kauer@koalo.de>
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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();
--- /dev/null
+From 341198eda723c8c1cddbb006a89ad9e362502ea2 Mon Sep 17 00:00:00 2001
+From: Leonid Iziumtsev <leonid.iziumtsev@gmail.com>
+Date: Tue, 15 Jan 2019 17:15:23 +0000
+Subject: dmaengine: imx-dma: fix wrong callback invoke
+
+From: Leonid Iziumtsev <leonid.iziumtsev@gmail.com>
+
+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 <leonid.iziumtsev@gmail.com>
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
--- /dev/null
+From cfa39381173d5f969daf43582c95ad679189cbc9 Mon Sep 17 00:00:00 2001
+From: Jann Horn <jannh@google.com>
+Date: Sat, 26 Jan 2019 01:54:33 +0100
+Subject: kvm: fix kvm_ioctl_create_device() reference counting (CVE-2019-6974)
+
+From: Jann Horn <jannh@google.com>
+
+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 <jannh@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From ecec76885bcfe3294685dc363fd1273df0d5d65f Mon Sep 17 00:00:00 2001
+From: Peter Shier <pshier@google.com>
+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 <pshier@google.com>
+
+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 <pshier@google.com>
+Reported-by: Jim Mattson <jmattson@google.com>
+Reviewed-by: Jim Mattson <jmattson@google.com>
+Reported-by: Felix Wilhelm <fwilhelm@google.com>
+Cc: stable@kernel.org
+Message-Id: <20181011184646.154065-1-pshier@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 353c0956a618a07ba4bbe7ad00ff29fe70e8412a Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+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 <pbonzini@redhat.com>
+
+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 <fwilhelm@google.com>
+Cc: stable@kernel.org
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
--- /dev/null
+From 9dff0aa95a324e262ffb03f425d00e4751f3294e Mon Sep 17 00:00:00 2001
+From: Mark Rutland <mark.rutland@arm.com>
+Date: Thu, 10 Jan 2019 14:27:45 +0000
+Subject: perf/core: Don't WARN() for impossible ring-buffer sizes
+
+From: Mark Rutland <mark.rutland@arm.com>
+
+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 <julien.thierry@arm.com>
+Signed-off-by: Mark Rutland <mark.rutland@arm.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Julien Thierry <julien.thierry@arm.com>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: <stable@vger.kernel.org>
+Link: https://lkml.kernel.org/r/20190110142745.25495-1-mark.rutland@arm.com
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
--- /dev/null
+From 489338a717a0dfbbd5a3fabccf172b78f0ac9015 Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
+Date: Tue, 22 Jan 2019 17:34:39 -0600
+Subject: perf tests evsel-tp-sched: Fix bitwise operator
+
+From: Gustavo A. R. Silva <gustavo@embeddedor.com>
+
+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 <gustavo@embeddedor.com>
+Acked-by: Jiri Olsa <jolsa@kernel.org>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Namhyung Kim <namhyung@kernel.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+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 <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From 9e63a7894fd302082cf3627fe90844421a6cbe7f Mon Sep 17 00:00:00 2001
+From: Kan Liang <kan.liang@linux.intel.com>
+Date: Sun, 27 Jan 2019 06:53:14 -0800
+Subject: perf/x86/intel/uncore: Add Node ID mask
+
+From: Kan Liang <kan.liang@linux.intel.com>
+
+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 <songliubraving@fb.com>
+Tested-by: Song Liu <songliubraving@fb.com>
+Signed-off-by: Kan Liang <kan.liang@linux.intel.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
+Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: <stable@vger.kernel.org> # 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 <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From 42caa0edabd6a0a392ec36a5f0943924e4954311 Mon Sep 17 00:00:00 2001
+From: James Bottomley <James.Bottomley@HansenPartnership.com>
+Date: Wed, 30 Jan 2019 16:42:12 -0800
+Subject: scsi: aic94xx: fix module loading
+
+From: James Bottomley <James.Bottomley@HansenPartnership.com>
+
+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 <James.Bottomley@HansenPartnership.com>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
--- /dev/null
+From fedb5760648a291e949f2380d383b5b2d2749b5e Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Thu, 31 Jan 2019 17:43:16 +0800
+Subject: serial: fix race between flush_to_ldisc and tty_open
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+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 <lirongqing@baidu.com>
+Tested-by: Li RongQing <lirongqing@baidu.com>
+Signed-off-by: Wang Li <wangli39@baidu.com>
+Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
+Signed-off-by: Li RongQing <lirongqing@baidu.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
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
--- /dev/null
+From c418fd6c01fbc5516a2cd1eaf1df1ec86869028a Mon Sep 17 00:00:00 2001
+From: Paul Elder <paul.elder@ideasonboard.com>
+Date: Wed, 30 Jan 2019 08:13:21 -0600
+Subject: usb: gadget: musb: fix short isoc packets with inventra dma
+
+From: Paul Elder <paul.elder@ideasonboard.com>
+
+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 <paul.elder@ideasonboard.com>
+Signed-off-by: Bin Liu <b-liu@ti.com>
+Cc: stable <stable@vger.kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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);
+ }
--- /dev/null
+From 07c69f1148da7de3978686d3af9263325d9d60bd Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
+Date: Tue, 22 Jan 2019 15:28:08 -0600
+Subject: usb: gadget: udc: net2272: Fix bitwise and boolean operations
+
+From: Gustavo A. R. Silva <gustavo@embeddedor.com>
+
+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 <gustavo@embeddedor.com>
+Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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;
+ }
--- /dev/null
+From a53469a68eb886e84dd8b69a1458a623d3591793 Mon Sep 17 00:00:00 2001
+From: Bin Liu <b-liu@ti.com>
+Date: Wed, 16 Jan 2019 11:54:07 -0600
+Subject: usb: phy: am335x: fix race condition in _probe
+
+From: Bin Liu <b-liu@ti.com>
+
+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 <b-liu@ti.com>
+Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ 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)
--- /dev/null
+From d28af26faa0b1daf3c692603d46bc4687c16f19e Mon Sep 17 00:00:00 2001
+From: Tony Luck <tony.luck@intel.com>
+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 <tony.luck@intel.com>
+
+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 <tony.luck@intel.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Cc: "H. Peter Anvin" <hpa@zytor.com>
+Cc: Ingo Molnar <mingo@redhat.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Vishal Verma <vishal.l.verma@intel.com>
+Cc: x86-ml <x86@kernel.org>
+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 <gregkh@linuxfoundation.org>
+
+---
+ 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;
projects / thirdparty / kernel / stable-queue.git / commitdiff
