From patchwork Thu Oct 17 15:26:06 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeffrey Hugo X-Patchwork-Id: 11196319 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0275214ED for ; Thu, 17 Oct 2019 15:26:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D4B9320872 for ; Thu, 17 Oct 2019 15:26:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hG6D9mH7" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2437985AbfJQP0S (ORCPT ); Thu, 17 Oct 2019 11:26:18 -0400 Received: from mail-pf1-f196.google.com ([209.85.210.196]:37696 "EHLO mail-pf1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2437754AbfJQP0S (ORCPT ); Thu, 17 Oct 2019 11:26:18 -0400 Received: by mail-pf1-f196.google.com with SMTP id y5so1877349pfo.4; Thu, 17 Oct 2019 08:26:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=vyhAg3anmutQrJfhNeqhS0F5n10v6jX+HPYL+lL5K0I=; b=hG6D9mH7YEkyNfA5TpZwHpvmyrgPd6IQ807A1WzZQm0y4pDM1ulNyhmIcZvfZDwjZ6 9RoCZYTJXpUX1BwnhX6Sbsw2fxZXKaJr4Cq3Qz4nsjvndWtwKVzP0KdPi1+pu5kW8ZMh nZHOAfHN8V/QbZp67gvCvqNGatkv4PgrGu1lH6q0gnT1Elxh8FpenGLBaABqOTzVZlGn iOiRj44ZR3V6X1ySRq+mIEqM6fDDx1oS5z99YouXlvsUrMnikH+Id9AbYAx39o5M08y1 Mgsty7zmfXCgK/q3qvwq/SHPFA8n5z4W2o0Ux/bu9H0qk9u71qhHVA7GaB4k+X9H01Rn nwJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=vyhAg3anmutQrJfhNeqhS0F5n10v6jX+HPYL+lL5K0I=; b=tKpFpcr1L8scSiR7fDSZjrpc5yCZi0lTZ79fd4ClFW1jwWSNWpUkoUm1f5GCklyW5l /FJvKVa8Bu4Ay2bx5rpI69+C4okKTeITuN9lgx7mVfzSdUOPK5vrgDFRYcEmnWmf4zNo wYMaJY455xK7hSynJaZVop39ON5miMkSVfoPAQVMvGuD5+PxK3u2fcb6Qm+0SGXd8ngB 3iA5fFhG5UGVy++uwOZc7VWUei+1pBbNqQcycq2s1yjWl8zb0dnFLhiVLELrohs3WcaA NAv104M3q6hSPgfHTGUB5gWcrVBuAbjfauoMPoImbL89tbX82FFek1In4izJ4X1RjevT DzRw== X-Gm-Message-State: APjAAAUZmoc5hprw/3fdx+XcMhEeiczvFSRFFFRdk0BpDCaEgglnuoWV 62v8i0TvjK9ctA9weNnEHbY= X-Google-Smtp-Source: APXvYqy8N7+VVeYK9qlx19Z7TSu4BOi9k5sVMTvNj2rcnFbeDrL1oI7LgG/3gr9vY1LJLwWer90Z1w== X-Received: by 2002:a17:90a:db12:: with SMTP id g18mr5119242pjv.32.1571325977238; Thu, 17 Oct 2019 08:26:17 -0700 (PDT) Received: from aw-bldr-10.qualcomm.com (i-global254.qualcomm.com. [199.106.103.254]) by smtp.gmail.com with ESMTPSA id t13sm3429237pfh.12.2019.10.17.08.26.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Oct 2019 08:26:16 -0700 (PDT) From: Jeffrey Hugo To: agross@kernel.org, bjorn.andersson@linaro.org, dan.j.williams@intel.com, vkoul@kernel.org Cc: linux-arm-msm@vger.kernel.org, dmaengine@vger.kernel.org, linux-kernel@vger.kernel.org, Jeffrey Hugo Subject: [PATCH] dmaengine: qcom: bam_dma: Fix resource leak Date: Thu, 17 Oct 2019 08:26:06 -0700 Message-Id: <20191017152606.34120-1-jeffrey.l.hugo@gmail.com> X-Mailer: git-send-email 2.17.1 Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org 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 --- drivers/dma/qcom/bam_dma.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c index 8e90a405939d..ef73f65224b1 100644 --- a/drivers/dma/qcom/bam_dma.c +++ b/drivers/dma/qcom/bam_dma.c @@ -694,6 +694,25 @@ static int bam_dma_terminate_all(struct dma_chan *chan) /* 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 (!list_empty(&bchan->desc_list)) { + async_desc = list_first_entry(&bchan->desc_list, + struct bam_async_desc, desc_node); + bam_chan_init_hw(bchan, async_desc->dir); + } + list_for_each_entry_safe(async_desc, tmp, &bchan->desc_list, desc_node) { list_add(&async_desc->vd.node, &bchan->vc.desc_issued);