[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170417175846.quedtrtjmfmthv2g@art_vandelay>
Date: Mon, 17 Apr 2017 13:58:46 -0400
From: Sean Paul <seanpaul@...omium.org>
To: Eric Anholt <eric@...olt.net>
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drm/vc4: Fix refcounting of runtime PM get if it errors
out.
On Mon, Apr 17, 2017 at 09:26:03AM -0700, Eric Anholt wrote:
> We were returning without decrementing if the error happened, meaning
> that at the next submit we wouldn't try to bring up the power domain.
>
> Signed-off-by: Eric Anholt <eric@...olt.net>
This change looks good to me. It seems a little odd to wrap pm_runtime which
is already refcounted in another refcount, but I'm really not familiar with
the driver, and I'm sure there's a good reason for it.
Reviewed-by: Sean Paul <seanpaul@...omium.org>
> ---
>
> I stumbled across this error when testing my CMA patch with a very low
> (64MB) CMA area -- we would oops on the submit after the one that
> failed.
>
> drivers/gpu/drm/vc4/vc4_gem.c | 13 ++++++++-----
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_gem.c b/drivers/gpu/drm/vc4/vc4_gem.c
> index 777a8d9afd60..735412e3725a 100644
> --- a/drivers/gpu/drm/vc4/vc4_gem.c
> +++ b/drivers/gpu/drm/vc4/vc4_gem.c
> @@ -1016,13 +1016,16 @@ vc4_submit_cl_ioctl(struct drm_device *dev, void *data,
> }
>
> mutex_lock(&vc4->power_lock);
> - if (vc4->power_refcount++ == 0)
> + if (vc4->power_refcount++ == 0) {
> ret = pm_runtime_get_sync(&vc4->v3d->pdev->dev);
> - mutex_unlock(&vc4->power_lock);
> - if (ret < 0) {
> - kfree(exec);
> - return ret;
> + if (ret < 0) {
> + mutex_unlock(&vc4->power_lock);
> + vc4->power_refcount--;
> + kfree(exec);
> + return ret;
> + }
> }
> + mutex_unlock(&vc4->power_lock);
>
> exec->args = args;
> INIT_LIST_HEAD(&exec->unref_list);
> --
> 2.11.0
--
Sean Paul, Software Engineer, Google / Chromium OS
Powered by blists - more mailing lists