]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
4.9-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 8 Nov 2019 14:04:24 +0000 (15:04 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 8 Nov 2019 14:04:24 +0000 (15:04 +0100)
added patches:
dmaengine-qcom-bam_dma-fix-resource-leak.patch

queue-4.9/dmaengine-qcom-bam_dma-fix-resource-leak.patch [new file with mode: 0644]
queue-4.9/series

diff --git a/queue-4.9/dmaengine-qcom-bam_dma-fix-resource-leak.patch b/queue-4.9/dmaengine-qcom-bam_dma-fix-resource-leak.patch
new file mode 100644 (file)
index 0000000..e7561a1
--- /dev/null
@@ -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
+@@ -686,7 +686,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;
+       }
index 3c9a9530b58c277882aef4669e82760937ff9661..93a38259da6bf84d88641c2a813dd2aec28fce8f 100644 (file)
@@ -30,3 +30,4 @@ kbuild-make-designated_init-attribute-fatal.patch
 kbuild-use-fmacro-prefix-map-to-make-__file__-a-rela.patch
 kbuild-add-fcf-protection-none-when-using-retpoline-.patch
 net-flow_dissector-switch-to-siphash.patch
+dmaengine-qcom-bam_dma-fix-resource-leak.patch