Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3162820pxj; Mon, 10 May 2021 20:57:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx8SXk1uBs3J06pp2R2TP660LByr4nXiXW123uLOtE0brxlrpUlClFphEhpDwsfj+zdkx0r X-Received: by 2002:a17:906:58d1:: with SMTP id e17mr29911749ejs.179.1620705467716; Mon, 10 May 2021 20:57:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620705467; cv=none; d=google.com; s=arc-20160816; b=0Aynm0eqV6XPe6j4YUiJUuVpZZVswwYqrx2EhscCLIj2kirVRF8A9jebmN9PszanUS eowBydU5EmGauegEuVanNiTcDrDSuHFa4flGisANXWDZQ31YlBoISrK/xvxCfKYObvXs bLfROx4nKvG/h8Iru4kuCJM8aJkqoVaGj88Moaef5JgCTp5fTkTv9IoxvyI0r55muX2x ylIyYhQos1af+nXGyszxBl9W5B/bAZ6URzWw9vxySGM5bC4vZjbPBfF5xFhz1VYZEoT7 UrHTW/k1JoC8smL7saiyuuzO5c2qEX4gNqdR8vP6kw80Xsr+ZTlotd1Fp8nSGuDPeeCa 0aAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:cc:references:to :subject; bh=zfVJgHlbvcjG16YHaRoqlbDwYQRiRfNUyyNn8vD4Vrk=; b=COlYRp/RPMEuWUe24RtjW9NgmPc/tNUq/UjUdea13a7qAdMNZHLGVdx6l6dzpnP0u2 drE5+r0VJOzkfZ2jXpPtSyBAOtYa5IgteGuwRfw0uw9+Tky6gOtAOarQwXzbRgm9/0Vl Rzwdn3ruRXbC6OPavAj0+fHKEbvGDfaN81SrW5NepneR0+2kUK/Rnq9ngmFv8/OYHVC/ ODvYYZrGSQxPO9y7aOcoq4Hajp3y5wRfQTSFEiMFu+qrZBDpwYsxMiAXGsVhoqdkEAIr 2amsV5+Fzosq/fxyLEOFgwUyxoiYR5A2V0fLh6UnS3iQn5VJmunyKnNsueYeA1Qe5jWY /zcg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g27si8119222ejb.616.2021.05.10.20.57.24; Mon, 10 May 2021 20:57:47 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230126AbhEKD47 (ORCPT + 99 others); Mon, 10 May 2021 23:56:59 -0400 Received: from szxga08-in.huawei.com ([45.249.212.255]:2297 "EHLO szxga08-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229465AbhEKD46 (ORCPT ); Mon, 10 May 2021 23:56:58 -0400 Received: from dggeml716-chm.china.huawei.com (unknown [172.30.72.57]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4FfP9j3K2pz19NW8; Tue, 11 May 2021 11:51:37 +0800 (CST) Received: from dggpemm500009.china.huawei.com (7.185.36.225) by dggeml716-chm.china.huawei.com (10.3.17.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Tue, 11 May 2021 11:55:50 +0800 Received: from [10.174.179.24] (10.174.179.24) by dggpemm500009.china.huawei.com (7.185.36.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Tue, 11 May 2021 11:55:50 +0800 Subject: Re: [PATCH 5.10 105/299] crypto: stm32/cryp - Fix PM reference leak on stm32-cryp.c To: Pavel Machek , Greg Kroah-Hartman References: <20210510102004.821838356@linuxfoundation.org> <20210510102008.407819731@linuxfoundation.org> <20210510120742.GC3547@duo.ucw.cz> CC: , , Herbert Xu , Sasha Levin From: Liu Shixin Message-ID: Date: Tue, 11 May 2021 11:55:48 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20210510120742.GC3547@duo.ucw.cz> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.179.24] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemm500009.china.huawei.com (7.185.36.225) X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/5/10 20:07, Pavel Machek wrote: > On Mon 2021-05-10 12:18:22, Greg Kroah-Hartman wrote: >> From: Shixin Liu >> >> [ Upstream commit 747bf30fd944f02f341b5f3bc7d97a13f2ae2fbe ] >> >> pm_runtime_get_sync will increment pm usage counter even it failed. >> Forgetting to putting operation will result in reference leak here. >> Fix it by replacing it with pm_runtime_resume_and_get to keep usage >> counter balanced. > Yes, but that only works when code checks the return value. Thank you for the correction. Yes, You are right that if we carry out runtime resume failed on the path where the return value is not checked, the pm usage counter will be put in later path. But I have another question. Why don't we check the return values in these path? Does that mean these resumes will never fail? >> +++ b/drivers/crypto/stm32/stm32-cryp.c >> @@ -542,7 +542,7 @@ static int stm32_cryp_hw_init(struct stm32_cryp *cryp) >> int ret; >> u32 cfg, hw_mode; >> >> - pm_runtime_get_sync(cryp->dev); >> + pm_runtime_resume_and_get(cryp->dev); >> >> /* Disable interrupt */ >> stm32_cryp_write(cryp, CRYP_IMSCR, 0); > Again, this is wrong. > >> @@ -2043,7 +2043,7 @@ static int stm32_cryp_remove(struct platform_device *pdev) >> if (!cryp) >> return -ENODEV; >> >> - ret = pm_runtime_get_sync(cryp->dev); >> + ret = pm_runtime_resume_and_get(cryp->dev); >> if (ret < 0) >> return ret; >> > But this may be right. > > Best regards, > Pavel