On Mon, Nov 4, 2019 at 10:12 AM Sasha Levin <sashal@xxxxxxxxxx> wrote:
>
> On Mon, Nov 04, 2019 at 07:39:58AM -0700, Jeffrey Hugo wrote:
> >On Mon, Nov 4, 2019 at 7:07 AM Sasha Levin <sashal@xxxxxxxxxx> wrote:
> >>
> >> On Mon, Nov 04, 2019 at 10:35:26AM +0100, gregkh@xxxxxxxxxxxxxxxxxxx wrote:
> >> >
> >> >The patch below does not apply to the 4.14-stable tree.
> >> >If someone wants it applied there, or to any other stable or longterm
> >> >tree, then please email the backport, including the original git commit
> >> >id to <stable@xxxxxxxxxxxxxxx>.
> >> >
> >> >thanks,
> >> >
> >> >greg k-h
> >> >
> >> >------------------ original commit in Linus's tree ------------------
> >> >
> >> >From 7667819385457b4aeb5fac94f67f52ab52cc10d5 Mon Sep 17 00:00:00 2001
> >> >From: Jeffrey Hugo <jeffrey.l.hugo@xxxxxxxxx>
> >> >Date: Thu, 17 Oct 2019 08:26:06 -0700
> >> >Subject: [PATCH] dmaengine: qcom: bam_dma: Fix resource leak
> >> >
> >> >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@xxxxxxxxx>
> >> >Cc: stable@xxxxxxxxxxxxxxx
> >> >Link: https://lore.kernel.org/r/20191017152606.34120-1-jeffrey.l.hugo@xxxxxxxxx
> >> >Signed-off-by: Vinod Koul <vkoul@xxxxxxxxxx>
> >>
> >> Is the "Fixes:" tag correct here? Is it an issue without 6b4faeac05bc
> >> ("dmaengine: qcom-bam: Process multiple pending descriptors")?
> >
> >Yes. The issue will occur, even if you submit only one descriptor.
> >The uart_dm driver which exposed this issue (msm_serial), only uses
> >one descriptor at a time, despite the hardware and some versions of
> >the bam driver allowing more than that.
> >
> >A trivial way to trigger this would be to queue a descriptor to
> >receive data from some peripheral that is attached to the BAM dma
> >engine, but the peripheral never sends that data - ie if you had a NIC
> >and you wanted to prequeue a receive buffer to accept an incoming
> >packet. If you then invoke terminate_all(), perhaps you need to
> >renegotiate the link speed of the NIC, you'll hit the same issue -
> >with or without "Process multiple pending descriptors".
>
> In this case I'll happily take a backport of this patch :)
I'll see what I can do in the next few days.
