From: Greg Kroah-Hartman Date: Fri, 8 Nov 2019 14:04:24 +0000 (+0100) Subject: 4.9-stable patches X-Git-Tag: v4.4.200~9 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=6b29cf9a68b6f56ff26e60c7f13a100c5bf90632;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: dmaengine-qcom-bam_dma-fix-resource-leak.patch --- 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 index 00000000000..e7561a1c57e --- /dev/null +++ b/queue-4.9/dmaengine-qcom-bam_dma-fix-resource-leak.patch @@ -0,0 +1,53 @@ +From 7667819385457b4aeb5fac94f67f52ab52cc10d5 Mon Sep 17 00:00:00 2001 +From: Jeffrey Hugo +Date: Thu, 17 Oct 2019 08:26:06 -0700 +Subject: dmaengine: qcom: bam_dma: Fix resource leak + +From: Jeffrey Hugo + +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 +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20191017152606.34120-1-jeffrey.l.hugo@gmail.com +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman + +--- + 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; + } diff --git a/queue-4.9/series b/queue-4.9/series index 3c9a9530b58..93a38259da6 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -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