Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3490832pxu; Mon, 30 Nov 2020 04:29:05 -0800 (PST) X-Google-Smtp-Source: ABdhPJzCtlJYiZSewREz952LsOuyO2cNNoILxKBm0QFob5GARLCzXgVMWB5oHfob6EpngtOzDFH0 X-Received: by 2002:a17:906:ce3c:: with SMTP id sd28mr20226917ejb.485.1606739345299; Mon, 30 Nov 2020 04:29:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606739345; cv=none; d=google.com; s=arc-20160816; b=aiVUpKMIHHjjvQh/Z0puiiKJOkWhTcEHkDYNwa6zxLmVXTtlFzbIVmG3LncXOyixOv e53bjjJb71rkbKT7+4V+h2oA4G12FXR9ZCVbROl2nAM6Fgv9IYQet3iSxufo3adrT/Ca kIe8pR2YAu/33QExjrhYr60sxVO+NYTepSs7YL5gwyswznLraYREfTat8tPOqjnzFNU+ 5SNwM+IXxx+g4fnI1FZa+c+g1ZrKQUYCkQEFJOz0beGrXXujSUznyfnIswJjfU2aMIvn rfAGTRV4jdz4VkPstjk1xo2u2A/W7EMG0HNPwaJEJMD9qot8ZOHjmDBhn1mYGrFlIZNb wt3A== 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:references:cc:to :subject; bh=FpC1e5n0pO7XYfOM4Jaw6+8hqkfmg+VVhq44VQhYnKI=; b=wIsQwtBg0/Db1AK0Edjcrwt6SXj0VHSsUQCZOOdSU5XM7M7EEb6nE/lpGN2jiVd0Ve EknZg64IAfuzDfwTqsxhIzLgLcYTKw00KtBc25ve6lHuHOtOZTfhR/mwT0xmNWpj/xxI l4zAUYOs629dsdpRPY7/ZcTcRSVY9HvPzc+HLI5q5nSZ4U6aZ1jIdGkT7ob50zsihW2B C7DczJEtUcnY9nnweFfkCCOjjMW0OSsjCM7RKnv7rUkiiX8NnJeEatwb93+ROh6DtDDg CyphVWESHdl5pw4Icnw+cOXW9YmVRVPJ8NegVmCcXFyK+OsLSkza9BpxofD6hW7nbeZc ZJCQ== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gf18si2321084ejb.202.2020.11.30.04.28.42; Mon, 30 Nov 2020 04:29:05 -0800 (PST) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725902AbgK3M1I (ORCPT + 99 others); Mon, 30 Nov 2020 07:27:08 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:9075 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725870AbgK3M1H (ORCPT ); Mon, 30 Nov 2020 07:27:07 -0500 Received: from DGGEMS410-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4Cl4Fs2JcjzLxpb; Mon, 30 Nov 2020 20:25:53 +0800 (CST) Received: from [10.174.177.149] (10.174.177.149) by DGGEMS410-HUB.china.huawei.com (10.3.19.210) with Microsoft SMTP Server id 14.3.487.0; Mon, 30 Nov 2020 20:26:21 +0800 Subject: Re: [PATCH] drm/panfrost: fix reference leak in panfrost_job_hw_submit To: Steven Price , Alyssa Rosenzweig , David Airlie , "Daniel Vetter" CC: Rob Herring , Tomeu Vizoso , , References: <20201127094441.121094-1-miaoqinglang@huawei.com> <46d1944e-fbbe-075f-1c5b-356b5ce73ee0@arm.com> From: Qinglang Miao Message-ID: Date: Mon, 30 Nov 2020 20:26:21 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <46d1944e-fbbe-075f-1c5b-356b5ce73ee0@arm.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.149] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2020/11/27 18:06, Steven Price 写道: > On 27/11/2020 09:44, Qinglang Miao wrote: >> pm_runtime_get_sync will increment pm usage counter even it >> failed. Forgetting to putting operation will result in a >> reference leak here. >> >> A new function pm_runtime_resume_and_get is introduced in >> [0] to keep usage counter balanced. So We fix the reference >> leak by replacing it with new funtion. >> >> [0] dd8088d5a896 ("PM: runtime: Add  pm_runtime_resume_and_get to deal >> with usage counter") >> >> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") >> Reported-by: Hulk Robot >> Signed-off-by: Qinglang Miao >> --- >>   drivers/gpu/drm/panfrost/panfrost_job.c | 2 +- >>   1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c >> b/drivers/gpu/drm/panfrost/panfrost_job.c >> index 30e7b7196..04cf3bb67 100644 >> --- a/drivers/gpu/drm/panfrost/panfrost_job.c >> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c >> @@ -147,7 +147,7 @@ static void panfrost_job_hw_submit(struct >> panfrost_job *job, int js) >>       panfrost_devfreq_record_busy(&pfdev->pfdevfreq); >> -    ret = pm_runtime_get_sync(pfdev->dev); >> +    ret = pm_runtime_resume_and_get(pfdev->dev); > > Sorry, but in this case this change isn't correct. > panfrost_job_hw_submit() is expected to be unbalanced (the PM reference > count is expected to be incremented on return). > > In the case where pm_runtime_get_sync() fails, the job will eventually > timeout, and there's a corresponding pm_runtime_put_noidle() in > panfrost_reset(). > > Potentially this could be handled better (e.g. without waiting for the > timeout to occur), but equally this isn't something we expect to happen > in normal operation). > > Steve Sorry, I didn't notice the pm_runtime_put_noidle() in panfrost_job_timedout() before. Thanks for your reply. > >>       if (ret < 0) >>           return; >> > > .