Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3849369ybz; Tue, 28 Apr 2020 01:17:48 -0700 (PDT) X-Google-Smtp-Source: APiQypKkxdQ30Ire9RIKk2r6uJghBeVVnQFAJjPamhkHAB4eF3rFKnvcpbVrb9JYsABLkxkN3/FW X-Received: by 2002:a17:906:3952:: with SMTP id g18mr24215554eje.191.1588061868808; Tue, 28 Apr 2020 01:17:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588061868; cv=none; d=google.com; s=arc-20160816; b=Izk9Knmwyfgx8CoJz8gT/XXOuPyDRXyzJux6q8tOqpCdY6Pf6vCiNF/CWOZ6LAC61/ r8z+QUo/BZPG+tsa6+XshkxXIkO0knGM28gT2V5ArUOdjxViLpdUpw5yqx6UJatKUqum oNNta3YAndtuvP7qK4UMJXkStkSZKntrBlyFLQADWqf/4HXBTmu3fuNEjTwOr2kJcQLP G2ZgtLuW/jekXDdA7ypnWyczrA8WUuZplAWy4jV9Q+8gOHd0kDmviObC7D8CI55Ej9Af Z2VioeQyqBtsa/R3cB/r4ajq6s6kipXocFYkEif1Mop7/PlBnY8gsy9WPobrjQSN9cDM l/bg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=3xjMu9onpulA2kur4sqLpTmL4sNgAay/v4viJL4Tx4s=; b=K7ZGNT1OH1sT/udURbTb49ymrtDiTFq0diYlQEfGaLtcRe6k3pucRuTE4unKcgPJQE 1eo3rFhfdZjv9jH+Nu0mjZypGECR48vlIiwW52MluOGmbqcyNkjMjvXrYkymt2TKPaCz tNJ0jc8U+yCa7oDu5QHF50I6rlu56dGG8GmO95uLShT9TMh5rh3LwpBZXu2XCrboIYQe AzmJec3JyIphPRbxreF145dWAE8iPEd5B3my3890Bmnj7DoMBVSkvJjD+H5W1weFdoF2 AtAEm9vTreiV/GW5oZ4BuBbEwQJJVo7tKc7/aNeEyCQrYbbyEzmvZZqKYImZi8W6gjQH cQyQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=OCWnPWOj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h10si1354440ejt.278.2020.04.28.01.17.25; Tue, 28 Apr 2020 01:17:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=OCWnPWOj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726759AbgD1INt (ORCPT + 99 others); Tue, 28 Apr 2020 04:13:49 -0400 Received: from fllv0015.ext.ti.com ([198.47.19.141]:50690 "EHLO fllv0015.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726765AbgD1INr (ORCPT ); Tue, 28 Apr 2020 04:13:47 -0400 Received: from fllv0035.itg.ti.com ([10.64.41.0]) by fllv0015.ext.ti.com (8.15.2/8.15.2) with ESMTP id 03S8CpPF056069; Tue, 28 Apr 2020 03:12:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1588061571; bh=3xjMu9onpulA2kur4sqLpTmL4sNgAay/v4viJL4Tx4s=; h=Subject:To:CC:References:From:Date:In-Reply-To; b=OCWnPWOjttsHUNxX57fKwHivjGFuY6igEVvRBP9h0uMk5SZ7A2DIAKtt7daZZMD84 gYBXiLNm/jfB1i7aRprHnHrSlG2YHkDba0v01kEX7kv4ZaBIzB3nmTZLrNJffmKCYD wXgFQRc8Mrk4Aa+68GcFX5Os7fWolGr0IXcU3PlE= Received: from DFLE100.ent.ti.com (dfle100.ent.ti.com [10.64.6.21]) by fllv0035.itg.ti.com (8.15.2/8.15.2) with ESMTP id 03S8CoG7009430; Tue, 28 Apr 2020 03:12:50 -0500 Received: from DFLE107.ent.ti.com (10.64.6.28) by DFLE100.ent.ti.com (10.64.6.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3; Tue, 28 Apr 2020 03:12:49 -0500 Received: from lelv0326.itg.ti.com (10.180.67.84) by DFLE107.ent.ti.com (10.64.6.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1979.3 via Frontend Transport; Tue, 28 Apr 2020 03:12:49 -0500 Received: from [192.168.2.6] (ileax41-snat.itg.ti.com [10.172.224.153]) by lelv0326.itg.ti.com (8.15.2/8.15.2) with ESMTP id 03S8Cljp056226; Tue, 28 Apr 2020 03:12:48 -0500 Subject: Re: [PATCH] ASoC: davinci-mcasp: Fix dma_chan refcnt leak when getting dma type To: Xiyu Yang , Liam Girdwood , Mark Brown , Jaroslav Kysela , Takashi Iwai , , CC: , , Xin Tan References: <1587818916-38730-1-git-send-email-xiyuyang19@fudan.edu.cn> From: Peter Ujfalusi Message-ID: Date: Tue, 28 Apr 2020 11:13:15 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <1587818916-38730-1-git-send-email-xiyuyang19@fudan.edu.cn> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 25/04/2020 15.48, Xiyu Yang wrote: > davinci_mcasp_get_dma_type() invokes dma_request_chan(), which returns a > reference of the specified dma_chan object to "chan" with increased > refcnt. > > When davinci_mcasp_get_dma_type() returns, local variable "chan" becomes > invalid, so the refcount should be decreased to keep refcount balanced. > > The reference counting issue happens in one exception handling path of > davinci_mcasp_get_dma_type(). When chan device is NULL, the function > forgets to decrease the refcnt increased by dma_request_chan(), causing > a refcnt leak. > > Fix this issue by calling dma_release_channel() when chan device is > NULL. > > Signed-off-by: Xiyu Yang > Signed-off-by: Xin Tan > --- > sound/soc/ti/davinci-mcasp.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/sound/soc/ti/davinci-mcasp.c b/sound/soc/ti/davinci-mcasp.c > index 734ffe925c4d..7a7db743dc5b 100644 > --- a/sound/soc/ti/davinci-mcasp.c > +++ b/sound/soc/ti/davinci-mcasp.c > @@ -1896,8 +1896,10 @@ static int davinci_mcasp_get_dma_type(struct davinci_mcasp *mcasp) > PTR_ERR(chan)); > return PTR_ERR(chan); > } > - if (WARN_ON(!chan->device || !chan->device->dev)) > + if (WARN_ON(!chan->device || !chan->device->dev)) { > + dma_release_channel(chan); > return -EINVAL; > + } If we get a channel then chan->device and chan->device->dev never NULL, it can not be. I think the reason why this is here is that static checkers tends to scream at us. Acked-by: Peter Ujfalusi > > if (chan->device->dev->of_node) > ret = of_property_read_string(chan->device->dev->of_node, > - Péter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki