From patchwork Thu Mar 16 10:56:02 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Wolfram Sang X-Patchwork-Id: 9627835 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id D019260522 for ; Thu, 16 Mar 2017 10:56:11 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C14C5279B3 for ; Thu, 16 Mar 2017 10:56:11 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B608228674; Thu, 16 Mar 2017 10:56:11 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 628A5285ED for ; Thu, 16 Mar 2017 10:56:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751973AbdCPK4K (ORCPT ); Thu, 16 Mar 2017 06:56:10 -0400 Received: from sauhun.de ([88.99.104.3]:35381 "EHLO pokefinder.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751964AbdCPK4K (ORCPT ); Thu, 16 Mar 2017 06:56:10 -0400 Received: from localhost (p54B33B74.dip0.t-ipconnect.de [84.179.59.116]) by pokefinder.org (Postfix) with ESMTPSA id EC2AD2C3118; Thu, 16 Mar 2017 11:56:04 +0100 (CET) From: Wolfram Sang To: linux-mmc@vger.kernel.org Cc: linux-renesas-soc@vger.kernel.org, Simon Horman , Kuninori Morimoto , Wolfram Sang Subject: [RFC] mmc: tmio: always unmap DMA before waiting for interrupt Date: Thu, 16 Mar 2017 11:56:02 +0100 Message-Id: <20170316105602.2581-1-wsa+renesas@sang-engineering.com> X-Mailer: git-send-email 2.11.0 Sender: linux-mmc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-mmc@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP In the (maybe academical) case, we don't get a DATAEND interrupt after DMA completed, we will wait endlessly for the completion to complete. This is not bad per se, since we have a more generic completion tracking a timeout. In that rare case, however, the DMA buffer will not get unmapped and we have a leak. Reorder the code, so unmapping will always take place. Signed-off-by: Wolfram Sang --- It's probably academical, still I think it is better to not have any leaks in favor of slightly more lock hazzling. Open for opionions, though, this is why I send out as RFC. drivers/mmc/host/tmio_mmc_dma.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/tmio_mmc_dma.c b/drivers/mmc/host/tmio_mmc_dma.c index c7684fa91f1f9c..e2093db2b7ffce 100644 --- a/drivers/mmc/host/tmio_mmc_dma.c +++ b/drivers/mmc/host/tmio_mmc_dma.c @@ -47,8 +47,6 @@ static void tmio_mmc_dma_callback(void *arg) { struct tmio_mmc_host *host = arg; - wait_for_completion(&host->dma_dataend); - spin_lock_irq(&host->lock); if (!host->data) @@ -63,6 +61,11 @@ static void tmio_mmc_dma_callback(void *arg) host->sg_ptr, host->sg_len, DMA_TO_DEVICE); + spin_unlock_irq(&host->lock); + + wait_for_completion(&host->dma_dataend); + + spin_lock_irq(&host->lock); tmio_mmc_do_data_irq(host); out: spin_unlock_irq(&host->lock);