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 :) -- Thanks, Sasha
