From: Daniel Vetter <daniel@ffwll.ch>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
DRI mailing list <dri-devel@lists.freedesktop.org>,
Daniel Vetter <daniel.vetter@intel.com>
Subject: Re: [git pull] drm fixes
Date: Mon, 2 Mar 2015 10:04:09 +0100 [thread overview]
Message-ID: <20150302090409.GV24485@phenom.ffwll.local> (raw)
In-Reply-To: <CA+55aFz94M0TVdf+jbKs-AHNJq5mZW8oo4pUOAqHS8qb_Cz9sA@mail.gmail.com>
On Sun, Mar 01, 2015 at 05:59:53PM -0800, Linus Torvalds wrote:
> On Sun, Mar 1, 2015 at 1:00 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > Back to the drawing board.
>
> Ok, many hours later, but I found it.
>
> The bisection was a disaster, having to work around other bugs in this
> area, but it ended up getting "close enough" that I figured out what
> went wrong.
Sorry for all the bisect work. Ville dug as far as the load detect being
unhappy due to atomic last week. But since I general don't real mail on
w/e I've only seen this thread now.
> The "intel_plane_duplicate_state()" is horribly horribly buggy. It
> looks at the state->fb pointer, but it may have been free'd already.
>
> This workaround "works for me", but it's really still very
> questionable, because while the "kref_get_unless_zero()" works
> correctly when the last reference has been dropped, I'm not sure that
> there is any guarantee that the whole allocation even exists any more,
> so I think the *correct* thing to do would be to clear state->fb when
> dropping the kref. But this was the smallest working patch I could
> come up with. Somebody who actually knows the code should start
> looking at the places that do drm_framebuffer_unreference(), and
> actually clear that pointer instead.
>
> Added Matt Roper and Ander Conselvan de Oliveira to the discussion,
> since they are the ones git says are involved with the original broken
> intel_plane_duplicate_state().
>
> Anyway, attached is
>
> (a) the patch with a big comment
>
> (b) the warnings I get on that machine that show where this problem
> triggers (and another warning earlier).
>
> Comments? I'm sure this probably only triggers with *old* X servers
> that don't do all the modern dri stuff.
It's not old X servers but old machines which don't have hotplug
interrupts (or still have tv-out, which doesn't have hpd support
anywhere).
I'll dig into this now just fyi the rules about how plane->state should be
handled:
- you need plane->lock
- it's invariant once assigned, updates should only be done with a
duplicate_state(), update state you want to change and the going through
the atomic commit machinery
- drm_plane_state->fb should always be a full reference
But switching to atomic amounts to a full rewrite of the drm core and
drivers (semantics for modeset updates are totally different). So there's
lots of glue and ducttape going on to keep up the illusion for both old
code and partially transitioned driver. It's all a bit wobbly atm and
don't loook too closely at some of the hacks we have.
And can you please attach a bactrace of the WARN in your patch, just to
double-check you blow up at the same spot?
Thanks, Daniel
> Linus
> From c182b15c3abee75cdc9d9564b6ab826403690f4e Mon Sep 17 00:00:00 2001
> From: Linus Torvalds <torvalds@localhost.localdomain>
> Date: Sat, 28 Feb 2015 21:44:48 -0800
> Subject: [PATCH] Workaround for drm bug
>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>
> ---
> drivers/gpu/drm/i915/intel_atomic_plane.c | 19 +++++++++++++++++--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index 9e6f727..72714d3 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -85,8 +85,23 @@ intel_plane_duplicate_state(struct drm_plane *plane)
> return NULL;
>
> state = &intel_state->base;
> - if (state->fb)
> - drm_framebuffer_reference(state->fb);
> +
> + /*
> + * We cannot do drm_framebuffer_reference(), because the reference
> + * may already have been dropped.
> + *
> + * So we do what drm_framebuffer_lookup() does, namely do a
> + * kref_get_unless_zero(). Even that is somewhat questionable,
> + * in that maybe the 'fb' already got free'd. So warn loudly
> + * about this.
> + *
> + * Maybe the base.fb should be cleared by whatever drops the
> + * reference?
> + */
> + if (state->fb && !kref_get_unless_zero(&state->fb->refcount)) {
> + state->fb = NULL;
> + WARN_ONCE(1, "intel_plane_duplicate_state got plane with dead frame buffer");
> + }
>
> return state;
> }
> --
> 2.3.1.167.g7f4ba4b
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2015-03-02 9:04 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <alpine.DEB.2.00.1502270441160.21188@skynet.skynet.ie>
2015-03-01 5:40 ` [git pull] drm fixes Linus Torvalds
2015-03-01 6:08 ` Linus Torvalds
2015-03-01 7:27 ` Linus Torvalds
2015-03-01 20:35 ` Linus Torvalds
2015-03-01 21:00 ` Linus Torvalds
2015-03-02 1:59 ` Linus Torvalds
2015-03-02 9:04 ` Daniel Vetter [this message]
2015-03-02 16:53 ` Linus Torvalds
2015-03-02 17:23 ` [Intel-gfx] " Daniel Vetter
2015-03-02 9:44 ` Paul Bolle
2015-03-02 10:26 ` Jani Nikula
2015-03-02 10:33 ` Daniel Vetter
2015-03-03 16:31 ` [PATCH] drm/i915: Fix modeset state confusion in the load detect code Daniel Vetter
2015-03-03 17:03 ` Linus Torvalds
2015-03-03 17:11 ` Daniel Vetter
2015-03-03 17:12 ` Linus Torvalds
2015-03-03 17:19 ` Daniel Vetter
2015-03-04 12:41 ` shuang.he
[not found] <alpine.DEB.2.00.1511200403280.14352@skynet.skynet.ie>
2015-11-27 19:05 ` [git pull] drm fixes Linus Torvalds
2015-11-27 19:36 ` Dave Airlie
2015-11-30 7:33 ` Daniel Vetter
2015-11-30 19:14 ` Linus Torvalds
[not found] <alpine.DEB.2.00.1503202149180.5859@skynet.skynet.ie>
2015-03-23 15:33 ` Josh Boyer
2015-03-23 18:34 ` Josh Boyer
2015-03-24 7:32 ` Daniel Vetter
2015-03-24 13:15 ` Josh Boyer
2015-03-24 13:40 ` [Intel-gfx] " Daniel Vetter
2015-03-24 13:57 ` Josh Boyer
2015-03-24 14:22 ` Josh Boyer
2015-03-24 14:34 ` [Intel-gfx] " Daniel Vetter
2015-03-24 14:46 ` Josh Boyer
2015-03-24 16:10 ` Josh Boyer
2015-03-24 16:48 ` Daniel Vetter
2015-03-24 16:49 ` [Intel-gfx] " Daniel Vetter
2015-03-24 16:54 ` Josh Boyer
2015-03-25 3:49 ` Xi Ruoyao
2015-03-25 8:54 ` Daniel Vetter
2015-03-25 13:11 ` [Intel-gfx] " Josh Boyer
2015-03-25 14:00 ` Daniel Vetter
2015-03-25 14:56 ` Xi Ruoyao
2015-03-25 15:12 ` Xi Ruoyao
2015-03-25 15:37 ` [Intel-gfx] " Josh Boyer
2015-03-25 15:50 ` Daniel Vetter
2015-03-25 15:53 ` Josh Boyer
2015-03-25 16:42 ` Josh Boyer
2015-03-25 17:17 ` Daniel Vetter
2015-03-25 17:37 ` Josh Boyer
2015-03-25 19:40 ` Josh Boyer
2015-03-25 23:32 ` Xi Ruoyao
2015-03-26 8:41 ` Xi Ruoyao
2015-03-24 1:41 ` Dave Jones
2015-03-25 8:56 ` Daniel Vetter
2015-03-25 14:34 ` Dave Jones
[not found] <alpine.DEB.2.00.1308300006570.10513@skynet.skynet.ie>
2013-08-31 23:02 ` Linus Torvalds
2013-09-01 20:10 ` Linus Torvalds
2013-09-02 6:54 ` Daniel Vetter
2013-09-02 16:53 ` Linus Torvalds
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=20150302090409.GV24485@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox