[Intel-gfx] [PATCH] drm: Drop grab fpriv->fbs_lock in drm_fb_release
Paulo Zanoni
przanoni at gmail.com
Wed Sep 24 22:30:00 CEST 2014
2014-09-24 16:55 GMT-03:00 Daniel Vetter <daniel.vetter at ffwll.ch>:
> Paulo Zanoni reported a lockdep splat with a locking inversion between
> fpriv->fbs_lock and the modeset locks. This issue was introduced in
>
> commit f2b50c1161590c3bcdbf3455fe4c575f1c1bd293
> Author: Daniel Vetter <daniel.vetter at ffwll.ch>
> Date: Fri Sep 12 17:07:32 2014 +0200
>
> drm: Fixup locking for universal cursor planes
>
> This here is actually one of the rare cases where lockdep hits a false
> positive: The deadlock only happens in drm_fb_release, which cleans up
> the file private structure when all the references are gone. So the
> locking is the very last one and no one else can deadlock. It also
> doesn't protect anything at all, since all ioctls are guaranteed to
> have returned at this point - otherwise they'd still hold a reference
> on the file.
>
> So let's just drop it and replace it with a big comment.
>
> Cc: David Herrmann <dh.herrmann at gmail.com>
> Cc: Matt Roper <matthew.d.roper at intel.com>
> Cc: Paulo Zanoni <przanoni at gmail.com>
> Reported-by: Paulo Zanoni <przanoni at gmail.com>
> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
Apparently, it fixes the problem I was seeing while running
igt/pm_rpm. It was not 100% reproducible, but it seems to be gone.
Smoke-tested-by: Paulo Zanoni <paulo.r.zanoni at intel.com>
Testcase: igt/pm_rpm
> ---
> drivers/gpu/drm/drm_crtc.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index b7021069b078..e79c8d3700d8 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3400,7 +3400,16 @@ void drm_fb_release(struct drm_file *priv)
> struct drm_device *dev = priv->minor->dev;
> struct drm_framebuffer *fb, *tfb;
>
> - mutex_lock(&priv->fbs_lock);
> + /*
> + * When the file gets released that means no one else can access the fb
> + * list any more, so no need to grab fpriv->fbs_lock. And we need to to
> + * avoid upsetting lockdep since the universal cursor code adds a
> + * framebuffer while holding mutex locks.
> + *
> + * Note that a real deadlock between fpriv->fbs_lock and the modeset
> + * locks is impossible here since no one else but this function can get
> + * at it any more.
> + */
> list_for_each_entry_safe(fb, tfb, &priv->fbs, filp_head) {
>
> mutex_lock(&dev->mode_config.fb_lock);
> @@ -3413,7 +3422,6 @@ void drm_fb_release(struct drm_file *priv)
> /* This will also drop the fpriv->fbs reference. */
> drm_framebuffer_remove(fb);
> }
> - mutex_unlock(&priv->fbs_lock);
> }
>
> /**
> --
> 2.1.0
>
--
Paulo Zanoni
More information about the Intel-gfx
mailing list