4.14-stable patches

added patches:
	dmaengine-qcom-bam_dma-fix-resource-leak.patch

diff --git a/queue-4.14/dmaengine-qcom-bam_dma-fix-resource-leak.patch b/queue-4.14/dmaengine-qcom-bam_dma-fix-resource-leak.patch
new file mode 100644 (file)
index 0000000..e18efdd
--- /dev/null
+++ b/queue-4.14/dmaengine-qcom-bam_dma-fix-resource-leak.patch
@@ -0,0 +1,53 @@
+From 7667819385457b4aeb5fac94f67f52ab52cc10d5 Mon Sep 17 00:00:00 2001
+From: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
+Date: Thu, 17 Oct 2019 08:26:06 -0700
+Subject: dmaengine: qcom: bam_dma: Fix resource leak
+
+From: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
+
+commit 7667819385457b4aeb5fac94f67f52ab52cc10d5 upstream.
+
+bam_dma_terminate_all() will leak resources if any of the transactions are
+committed to the hardware (present in the desc fifo), and not complete.
+Since bam_dma_terminate_all() does not cause the hardware to be updated,
+the hardware will still operate on any previously committed transactions.
+This can cause memory corruption if the memory for the transaction has been
+reassigned, and will cause a sync issue between the BAM and its client(s).
+
+Fix this by properly updating the hardware in bam_dma_terminate_all().
+
+Fixes: e7c0fe2a5c84 ("dmaengine: add Qualcomm BAM dma driver")
+Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20191017152606.34120-1-jeffrey.l.hugo@gmail.com
+Signed-off-by: Vinod Koul <vkoul@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/dma/qcom/bam_dma.c |   14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+--- a/drivers/dma/qcom/bam_dma.c
++++ b/drivers/dma/qcom/bam_dma.c
+@@ -690,7 +690,21 @@ static int bam_dma_terminate_all(struct
+ 
+       /* remove all transactions, including active transaction */
+       spin_lock_irqsave(&bchan->vc.lock, flag);
++      /*
++       * If we have transactions queued, then some might be committed to the
++       * hardware in the desc fifo.  The only way to reset the desc fifo is
++       * to do a hardware reset (either by pipe or the entire block).
++       * bam_chan_init_hw() will trigger a pipe reset, and also reinit the
++       * pipe.  If the pipe is left disabled (default state after pipe reset)
++       * and is accessed by a connected hardware engine, a fatal error in
++       * the BAM will occur.  There is a small window where this could happen
++       * with bam_chan_init_hw(), but it is assumed that the caller has
++       * stopped activity on any attached hardware engine.  Make sure to do
++       * this first so that the BAM hardware doesn't cause memory corruption
++       * by accessing freed resources.
++       */
+       if (bchan->curr_txd) {
++              bam_chan_init_hw(bchan, bchan->curr_txd->dir);
+               list_add(&bchan->curr_txd->vd.node, &bchan->vc.desc_issued);
+               bchan->curr_txd = NULL;
+       }

diff --git a/queue-4.14/series b/queue-4.14/series
index fac684cd87cbd849be0151b82cdcc9eab2f96e10..392f289ca0b9c78c30001c26a4c41f30d3906560 100644 (file)
--- a/queue-4.14/series
+++ b/queue-4.14/series
@@ -47,5 +47,6 @@ vxlan-check-tun_info-options_len-properly.patch
 erspan-fix-the-tun_info-options_len-check-for-erspan.patch
 inet-stop-leaking-jiffies-on-the-wire.patch
 net-flow_dissector-switch-to-siphash.patch
+dmaengine-qcom-bam_dma-fix-resource-leak.patch
 kbuild-use-fmacro-prefix-map-to-make-__file__-a-rela.patch
 kbuild-add-fcf-protection-none-when-using-retpoline-.patch