Thread (6 messages) 6 messages, 4 authors, 2011-06-15

Re: Possible deadlock when suspending framebuffer

From: Wanlong Gao <hidden>
Date: 2011-06-15 06:23:05
Also in: lkml

On Wed, Jun 15, 2011 at 1:58 PM, Bruno Prémont
[off-list ref] wrote:
Hi,

On Wed, 15 Jun 2011 09:09:24 Wanlong Gao [off-list ref] wrote:
quoted
<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?
Thanks
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

quoted
Thanks
<snip>

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help