Messages in this thread |  | | Subject | Re: [PATCH] drm/panfrost: fix ref count leak in panfrost_job_hw_submit | From | Steven Price <> | Date | Thu, 9 Jul 2020 16:59:13 +0100 |
| |
On 09/07/2020 16:44, Rob Herring wrote: > On Sun, Jun 14, 2020 at 12:27 AM Navid Emamdoost > <navid.emamdoost@gmail.com> wrote: >> >> in panfrost_job_hw_submit, pm_runtime_get_sync is called which >> increments the counter even in case of failure, leading to incorrect >> ref count. In case of failure, decrement the ref count before returning. >> >> Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> >> --- >> drivers/gpu/drm/panfrost/panfrost_job.c | 8 +++++--- >> 1 file changed, 5 insertions(+), 3 deletions(-) >> >> diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c b/drivers/gpu/drm/panfrost/panfrost_job.c >> index 7914b1570841..89ac84667eb1 100644 >> --- a/drivers/gpu/drm/panfrost/panfrost_job.c >> +++ b/drivers/gpu/drm/panfrost/panfrost_job.c >> @@ -147,11 +147,10 @@ static void panfrost_job_hw_submit(struct panfrost_job *job, int js) >> >> ret = pm_runtime_get_sync(pfdev->dev); >> if (ret < 0) >> - return; >> + goto out; > > If the get failed, I don't think we want to do a put.
The pm_runtime_get_sync() does actually always increment the reference (even when returning a failure), but actually I don't think we want it here anyway, as I think I explained before[1]. [1] https://lore.kernel.org/dri-devel/272650ba-2c44-9084-7829-b04023eba723@arm.com > >> >> if (WARN_ON(job_read(pfdev, JS_COMMAND_NEXT(js)))) { >> - pm_runtime_put_sync_autosuspend(pfdev->dev);
This is a correct change - we don't want the put here. (Although this should never happen).
>> - return; >> + goto out; >> } >> >> cfg = panfrost_mmu_as_get(pfdev, &job->file_priv->mmu); >> @@ -184,6 +183,9 @@ static void panfrost_job_hw_submit(struct panfrost_job *job, int js) >> job, js, jc_head); >> >> job_write(pfdev, JS_COMMAND_NEXT(js), JS_COMMAND_START); > > So we start the job here and then... > >> +out: >> + pm_runtime_put_sync_autosuspend(pfdev->dev); > > ...turn off clocks/power here. Typically, you'd be fine as autosuspend > has a delay by default, but userspace is free to change the delay to > 0. > >> + return;
A return at the end of the function with no argument is pointless.
Steve
>> } >> >> static void panfrost_acquire_object_fences(struct drm_gem_object **bos, >> -- >> 2.17.1 >>
|  |