Re: [PATCH 1/2] fb: Rework locking to fix lock ordering on takeover

From
Takashi Iwai <hidden>
Date
2013-01-23 16:38:46
Also in
dri-devel, intel-gfx, lkml
Reply to
Daniel Vetter, 2013-01-23
At Wed, 23 Jan 2013 17:25:08 +0100,
Daniel Vetter wrote:
From: Alan Cox <redacted>

Adjust the console layer to allow a take over call where the caller already
holds the locks. Make the fb layer lock in order.

This s partly a band aid, the fb layer is terminally confused about the
locking rules it uses for its notifiers it seems.

Signed-off-by: Alan Cox <redacted>
[danvet: Tiny whitespace cleanup.]
Reported-and-tested-by: Hugh Dickins <hughd@google.com>
Reported-and-tested-by: Sasha Levin <redacted>
References: https://lkml.org/lkml/2012/10/25/516
Signed-off-by: Daniel Vetter <redacted>
FYI, the latest patch of this is found in mm tree:
  http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch

Also I hit the same problem in another code paths (for unbind and
unregister):
  http://marc.info/?t=135309396400003&r=1&w=2

My additional patch is found in mm tree, too:
  http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch


Takashi
Thread (6 messages) 6 messages, 3 authors, last reply 2013-01-24
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help