All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Herrmann <dh.herrmann@gmail.com>
To: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI Development <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH] drm/fbdev: Update legacy plane->fb refcounting for atomic restore
Date: Tue, 22 Sep 2015 13:02:44 +0200	[thread overview]
Message-ID: <CANq1E4Tjr2LvMwjPNDKFpyVTu-AQizhp8LKB0n3TWk_zSX_3bg@mail.gmail.com> (raw)
In-Reply-To: <1442919402-4451-1-git-send-email-daniel.vetter@ffwll.ch>

Hi

On Tue, Sep 22, 2015 at 12:56 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> From: Matt Roper <matthew.d.roper@intel.com>
>
> Starting with commit
>
>         commit 28cc504e8d52248962f5b485bdc65f539e3fe21d
>         Author: Rob Clark <robdclark@gmail.com>
>         Date:   Tue Aug 25 15:36:00 2015 -0400
>
>             drm/i915: enable atomic fb-helper
>
> I've been seeing some panics on i915 when the DRM master shuts down that appear
> to be caused by using an already-freed framebuffer (i.e., we're unexpectedly
> dropping our initial FB's reference count to 0 and freeing it, which causes a
> crash when we try to restore it later).  Digging deeper, the state FB
> refcounting is working as expected, but we seem to be missing proper
> refcounting on the legacy plane->fb pointers in the new atomic fbdev code.
>
> Tracking plane->old_fb and then doing a ref/unref at the end of the
> fbdev restore like we do in the legacy ioctl's ensures we don't miscount
> references on plane->fb and avoids the panics.
>
> v2 from Daniel:
>
> Really do what the atomic ioctl does:
> - Also update plane->fb and plane->crtc.
> - Clear out plane->old_fb on failures too.
>
> v3: git add everything. Oops.
>
> Cc: Rob Clark <robdclark@gmail.com>
> Cc: intel-gfx@lists.freedesktop.org
> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> (v1)
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 17 +++++++++++++++++
>  1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 64fc5ca8fda2..8af522afdfc1 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -352,6 +352,8 @@ retry:
>         drm_for_each_plane(plane, dev) {
>                 struct drm_plane_state *plane_state;
>
> +               plane->old_fb = plane->fb;
> +
>                 plane_state = drm_atomic_get_plane_state(state, plane);
>                 if (IS_ERR(plane_state)) {
>                         ret = PTR_ERR(plane_state);
> @@ -382,6 +384,21 @@ retry:
>         }
>
>         ret = drm_atomic_commit(state);
> +
> +       drm_for_each_plane(plane, dev) {
> +               if (ret == 0) {
> +                       struct drm_framebuffer *new_fb = plane->state->fb;
> +                       if (new_fb)
> +                               drm_framebuffer_reference(new_fb);
> +                       plane->fb = new_fb;
> +                       plane->crtc = plane->state->crtc;
> +
> +                       if (plane->old_fb)
> +                               drm_framebuffer_unreference(plane->old_fb);
> +               }
> +               plane->old_fb = NULL;

You still leak "old_fb" if something jumps to "fail:" before
drm_atomic_commit() is called. But I don't mind:

Reviewed-by: David Herrmann <dh.herrmann@gmail.com>

Thanks
David

> +       }
> +
>         if (ret != 0)
>                 goto fail;
>
> --
> 2.5.1
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

      reply	other threads:[~2015-09-22 11:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-22  0:21 [PATCH] drm/fbdev: Update legacy plane->fb refcounting for atomic restore Matt Roper
2015-09-22  9:55 ` Daniel Vetter
2015-09-22 10:33   ` Maarten Lankhorst
2015-09-22 10:34     ` David Herrmann
2015-09-22 10:33   ` David Herrmann
2015-09-22 10:56 ` Daniel Vetter
2015-09-22 11:02   ` David Herrmann [this message]

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=CANq1E4Tjr2LvMwjPNDKFpyVTu-AQizhp8LKB0n3TWk_zSX_3bg@mail.gmail.com \
    --to=dh.herrmann@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.