Re: FAILED: patch "[PATCH] dmaengine: qcom: bam_dma: Fix resource leak" failed to apply to 4.14-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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".
>
> --
> Thanks,
> Sasha



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux