On Wed, Jan 23, 2013 at 5:38 PM, Takashi Iwai <[email protected]> wrote: > At Wed, 23 Jan 2013 17:25:08 +0100, > Daniel Vetter wrote: >> >> From: Alan Cox <[email protected]> >> >> 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 <[email protected]> >> [danvet: Tiny whitespace cleanup.] >> Reported-and-tested-by: Hugh Dickins <[email protected]> >> Reported-and-tested-by: Sasha Levin <[email protected]> >> References: https://lkml.org/lkml/2012/10/25/516 >> Signed-off-by: Daniel Vetter <[email protected]> > > 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
Indeed, there's more stuff :( And I've missed the export_symbol fix for the first patch. Still, is there any chance we can at least merge the first one (I don't think that many people unload framebuffers) into 3.8 with cc: stable? I'd like to get at least rid of the known deadlocks at kms takeover time, since we have quite a few unexplained such bug reports floating around ... Andrew, Dave? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
