Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1205672pxu; Fri, 27 Nov 2020 02:10:41 -0800 (PST) X-Google-Smtp-Source: ABdhPJz1fJuWE2Qm6gw7b276H1HlBgijRTaECl3uHtvPaD4nRkaLUJfi0xazl2nUgrkUVsXYz0HL X-Received: by 2002:a05:6402:845:: with SMTP id b5mr1314851edz.38.1606471841247; Fri, 27 Nov 2020 02:10:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1606471841; cv=none; d=google.com; s=arc-20160816; b=EygZe7/YA4WcpQJNHA1cubkda5Puyi991JkaBOMbXKQOa3SmJpjB2uw28NczTaDJHj XbizBlHlIZBmhUOhr9/9uTCwGKzwHUhKq12UkmsNBj9r8J2hryzAWJc2+wiQfW5VGJxM R+39QsUt0hHbMzKapJFL8UYngK6MGXYZ89ehLUdUkkDAfxtHYtkz0DhK2OVdaEVc57In lyptw8XrbBQbsWoT8zfMhmOLYCBDCwaLqKdrE9Dmeb82H4mvhy5SU2ueqCxFH+i3DnYA CEEGHNWH0DTQT0qyqi6bo25qWhlfWN+neNsiVINF1qH5u0/PDUiigsWaoZKEkV27Y0yG RJyQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=LmV65akmQfsMIsOXl0OyveDx9pA+eS52dQwF2iigXpk=; b=MrdUqICoUicA8gsoRtwWsgyBXsF5wertCH9MQv3MuTuEm1UG2408rOWJ3L8bgu3t1q zmYT1Q8QSYlAXgLmlramcWuTAVN3sd8pS6xLvRw6C2Z5YX61ImGa2n8yPLikzsIz/qrH d5UuAvh748mkt2Hrh7uGqk8IkIzVqKWFtQsIwui+ol5DL1vXhKsMnzXCrif/aBb5aMR+ ik2hYBVqV1Q9iad7z3fswDHnXL5AVrM6Ei+J3uSYon2lgzY7KFh67O80k4tAbEbDzgkk FEY8aNBI/5TakGl0HXwdGpjyFuji2ZO8zmRiBG7lIWsvyVCRewMVjA9cGpmw6RZ/wgf3 5FFA== 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=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u19si5731505edo.433.2020.11.27.02.10.18; Fri, 27 Nov 2020 02:10:41 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728451AbgK0KGZ (ORCPT + 99 others); Fri, 27 Nov 2020 05:06:25 -0500 Received: from foss.arm.com ([217.140.110.172]:36722 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726202AbgK0KGZ (ORCPT ); Fri, 27 Nov 2020 05:06:25 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4293C1516; Fri, 27 Nov 2020 02:06:24 -0800 (PST) Received: from [192.168.1.179] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2F2D93F71F; Fri, 27 Nov 2020 02:06:23 -0800 (PST) Subject: Re: [PATCH] drm/panfrost: fix reference leak in panfrost_job_hw_submit To: Qinglang Miao , Rob Herring , Tomeu Vizoso , Alyssa Rosenzweig , David Airlie , Daniel Vetter Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20201127094441.121094-1-miaoqinglang@huawei.com> From: Steven Price Message-ID: <46d1944e-fbbe-075f-1c5b-356b5ce73ee0@arm.com> Date: Fri, 27 Nov 2020 10:06:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20201127094441.121094-1-miaoqinglang@huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > if (ret < 0) > return; > >