[lkml]   [2011]   [Jun]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Possible deadlock when suspending framebuffer
On Wed, Jun 15, 2011 at 1:58 PM, Bruno Prémont
<> wrote:
> Hi,
> On Wed, 15 Jun 2011 09:09:24 Wanlong Gao <> wrote:
> > <snip>
> > Hi Francis:
> > can you test this patch?
> Do you have a deadlock trace which you are trying to fix?
No, I just look at the code and try to fix this but I'm not sure.
Can you teach me how to have a deadlock trace here?
> It's either the caller of unregister_framebuffer() which must be
> changed to not call unregister_framebuffer with info's lock held or
> the code reacting on the notification that must not try to acquire the
> lock again.
> The interesting par is if console semaphore has some relation to this
> deadlock as the order for taking both varies... It could be
> lock_fb_info(); console_lock()  versus console_lock(); lock_fb_info()
I see, thanks
> Bruno
> > Thanks
> >
> Not a good idea to stop taking fb_lock here.
> Pretty all calls of fb_notifier_call_chain are protected by info's
> lock, except the one for FB_EVENT_FB_UNREGISTERED a few lines further.
Yup, thanks
> IMHO it wou make sense to add the lock around that last one so all
> notifier chain calls are handled the same.
> <snip>

Best regards
Wanlong Gao
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2011-06-15 08:25    [W:0.054 / U:14.396 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site