From: Daniel Vetter <daniel@ffwll.ch>
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v2] drm/atomic: Handle vblank events in atomic ioctl correctly.
Date: Mon, 15 Jun 2015 08:22:46 +0200 [thread overview]
Message-ID: <20150615062246.GA8341@phenom.ffwll.local> (raw)
In-Reply-To: <556D549E.1010109@linux.intel.com>
On Tue, Jun 02, 2015 at 09:00:46AM +0200, Maarten Lankhorst wrote:
> All users of async updates seem to clear clear crtc_state->event
> correctly, so move destroying vblank event to crtc_destroy_state.
>
> This is better than manually free'ing it in the atomic ioctl, since
> this code seems to do it wrong.
>
> While we're at it handle -EDEADLK from atomic_commit correctly,
> because the check might fail otherwise if it takes additional state.
Please don't smash unrelated fixes together into the same patch.
> Changes since v1:
> - Fix freeing a NULL framebuffer, thanks for catching Daniel Stone.
>
> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Reviewed-by: Daniel Stone <daniels@collabora.com>
> ---
> drivers/gpu/drm/drm_atomic.c | 45 +++++++++----------------------------
> drivers/gpu/drm/drm_atomic_helper.c | 15 +++++++++++++
> 2 files changed, 26 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c7e59b074e62..8add0dd8dc5d 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1328,17 +1328,6 @@ out:
> return e;
> }
>
> -static void destroy_vblank_event(struct drm_device *dev,
> - struct drm_file *file_priv, struct drm_pending_vblank_event *e)
> -{
> - unsigned long flags;
> -
> - spin_lock_irqsave(&dev->event_lock, flags);
> - file_priv->event_space += sizeof e->event;
> - spin_unlock_irqrestore(&dev->event_lock, flags);
> - kfree(e);
> -}
> -
> static int atomic_set_prop(struct drm_atomic_state *state,
> struct drm_mode_object *obj, struct drm_property *prop,
> uint64_t prop_value)
> @@ -1534,13 +1523,18 @@ retry:
> if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
> ret = drm_atomic_check_only(state);
> /* _check_only() does not free state, unlike _commit() */
> - drm_atomic_state_free(state);
> + if (!ret)
> + drm_atomic_state_free(state);
> } else if (arg->flags & DRM_MODE_ATOMIC_NONBLOCK) {
> ret = drm_atomic_async_commit(state);
> } else {
> ret = drm_atomic_commit(state);
> }
>
> +fail:
> + if (ret == -EDEADLK)
> + goto backoff;
> +
> /* if succeeded, fixup legacy plane crtc/fb ptrs before dropping
> * locks (ie. while it is still safe to deref plane->state). We
> * need to do this here because the driver entry points cannot
> @@ -1553,32 +1547,15 @@ retry:
> drm_framebuffer_reference(new_fb);
> plane->fb = new_fb;
> plane->crtc = plane->state->crtc;
> - } else {
> - plane->old_fb = NULL;
> - }
> - if (plane->old_fb) {
> - drm_framebuffer_unreference(plane->old_fb);
> - plane->old_fb = NULL;
> - }
> - }
> -
> - drm_modeset_drop_locks(&ctx);
> - drm_modeset_acquire_fini(&ctx);
> -
> - return ret;
> -
> -fail:
> - if (ret == -EDEADLK)
> - goto backoff;
We have a pre-existing bug here already of leaking plane->old_fb before
dropping locks. I think the EDEADLK case needs to be after the cleanup
loop to clear old_fb.
-Daniel
>
> - if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT) {
> - for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - destroy_vblank_event(dev, file_priv, crtc_state->event);
> - crtc_state->event = NULL;
> + if (plane->old_fb)
> + drm_framebuffer_unreference(plane->old_fb);
> }
> + plane->old_fb = NULL;
> }
>
> - drm_atomic_state_free(state);
> + if (ret)
> + drm_atomic_state_free(state);
>
> drm_modeset_drop_locks(&ctx);
> drm_modeset_acquire_fini(&ctx);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> index 536ae4da4665..0bb70c4da77a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2101,6 +2101,18 @@ drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc)
> }
> EXPORT_SYMBOL(drm_atomic_helper_crtc_duplicate_state);
>
> +static void destroy_vblank_event(struct drm_device *dev,
> + struct drm_pending_vblank_event *e)
> +{
> + struct drm_file *file_priv = e->base.file_priv;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&dev->event_lock, flags);
> + file_priv->event_space += sizeof e->event;
> + spin_unlock_irqrestore(&dev->event_lock, flags);
> + kfree(e);
> +}
> +
> /**
> * __drm_atomic_helper_crtc_destroy_state - release CRTC state
> * @crtc: CRTC object
> @@ -2115,6 +2127,9 @@ void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc *crtc,
> {
> if (state->mode_blob)
> drm_property_unreference_blob(state->mode_blob);
> +
> + if (state->event)
> + destroy_vblank_event(crtc->dev, state->event);
> }
> EXPORT_SYMBOL(__drm_atomic_helper_crtc_destroy_state);
>
> --
> 2.1.0
>
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-06-15 6:20 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-01 18:12 [PATCH] drm/atomic: Handle vblank events in atomic ioctl correctly Maarten Lankhorst
2015-06-01 18:20 ` Daniel Stone
2015-06-02 7:00 ` [PATCH v2] " Maarten Lankhorst
2015-06-15 6:22 ` Daniel Vetter [this message]
2015-06-15 8:42 ` [Intel-gfx] " Maarten Lankhorst
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150615062246.GA8341@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=maarten.lankhorst@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox