[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <s5hk3r3etwt.wl%tiwai@suse.de>
Date: Wed, 23 Jan 2013 17:38:42 +0100
From: Takashi Iwai <tiwai@...e.de>
To: Daniel Vetter <daniel.vetter@...ll.ch>
Cc: Dave Airlie <airlied@...il.com>,
Intel Graphics Development <intel-gfx@...ts.freedesktop.org>,
DRI Development <dri-devel@...ts.freedesktop.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-fbdev-devel@...ts.sourceforge.net,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Alan Cox <alan@...ux.intel.com>
Subject: Re: [PATCH 1/2] fb: Rework locking to fix lock ordering on takeover
At Wed, 23 Jan 2013 17:25:08 +0100,
Daniel Vetter wrote:
>
> From: Alan Cox <alan@...rguk.ukuu.org.uk>
>
> 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 <alan@...ux.intel.com>
> [danvet: Tiny whitespace cleanup.]
> Reported-and-tested-by: Hugh Dickins <hughd@...gle.com>
> Reported-and-tested-by: Sasha Levin <levinsasha928@...il.com>
> References: https://lkml.org/lkml/2012/10/25/516
> Signed-off-by: Daniel Vetter <daniel.vetter@...ll.ch>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists