From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AC176CA9EB5 for ; Mon, 4 Nov 2019 17:12:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8209B2080F for ; Mon, 4 Nov 2019 17:12:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572887557; bh=wXgj5KYM6aKDn65vEYDH15xmk8HLySgDVSPzhMWiSDo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=XvcuEXba2A4o32Qp6iPrL2nHQDo5f747QfhWFUTgZcRY92VJv14l3IYop3UjDqqLv XWSxk81wf+nTukPizxYBxaSXHDIjK8FFaccDHYhL+CqNWwCp0w51U5b+8s4HfqES4R r4nZE0kfG7t6VZmhZk/XB1rkP6BMOy7lFfrrvRGQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727998AbfKDRMh (ORCPT ); Mon, 4 Nov 2019 12:12:37 -0500 Received: from mail.kernel.org ([198.145.29.99]:46946 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727989AbfKDRMg (ORCPT ); Mon, 4 Nov 2019 12:12:36 -0500 Received: from localhost (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 7BC8A2080F; Mon, 4 Nov 2019 17:12:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572887555; bh=wXgj5KYM6aKDn65vEYDH15xmk8HLySgDVSPzhMWiSDo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=uP66pwTMfLTQWoaPHsSa73ReGAo+539bR400JF6edaFMn4DzzeE05WUxc0kFlapBg NrH6HTy1qSyehQMFebh2sLxCt/5AX0Oq7vk3ZgRJO5AWgCb/hT/VytGbesB2strLbF gNKfUCFEed0UYcPY/WwdhaixVwCqXE0aZW7WJsiw= Date: Mon, 4 Nov 2019 12:12:34 -0500 From: Sasha Levin To: Jeffrey Hugo Cc: Greg Kroah-Hartman , vkoul@kernel.org, stable@vger.kernel.org Subject: Re: FAILED: patch "[PATCH] dmaengine: qcom: bam_dma: Fix resource leak" failed to apply to 4.14-stable tree Message-ID: <20191104171234.GF4787@sasha-vm> References: <15728601263783@kroah.com> <20191104140713.GE4787@sasha-vm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org On Mon, Nov 04, 2019 at 07:39:58AM -0700, Jeffrey Hugo wrote: >On Mon, Nov 4, 2019 at 7:07 AM Sasha Levin wrote: >> >> On Mon, Nov 04, 2019 at 10:35:26AM +0100, gregkh@linuxfoundation.org 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 . >> > >> >thanks, >> > >> >greg k-h >> > >> >------------------ original commit in Linus's tree ------------------ >> > >> >From 7667819385457b4aeb5fac94f67f52ab52cc10d5 Mon Sep 17 00:00:00 2001 >> >From: Jeffrey Hugo >> >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 >> >Cc: stable@vger.kernel.org >> >Link: https://lore.kernel.org/r/20191017152606.34120-1-jeffrey.l.hugo@gmail.com >> >Signed-off-by: Vinod Koul >> >> 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