http://bugzilla.suse.com/show_bug.cgi?id=1051059 http://bugzilla.suse.com/show_bug.cgi?id=1051059#c22 --- Comment #22 from Joey Lee <jlee@suse.com> --- Sorry for my delay! (In reply to Takashi Iwai from comment #19)

Created attachment 734772 [details] Revised patch

Thanks for Takashi's help! I have reviewed this patch. It's good to me. (In reply to Takashi Iwai from comment #16) [...snip]

I'm not sure whether it's safe to assume that. Basically you're calling some sleepable functions like mutex or kmalloc with GFP_KERNEL inside the local irq-disabled context. This may not work.

Is that because using sleepable functions in irq-disabled context that it may causes the irq disable too long then causes hard lock?

I guess the problem is only in the crypto shash allocation and initialization. If so, a better option would be to move it before the actual swsusp_arch_suspend() call.

Maybe we can define swsusp_arch_suspend_prepare() and call it in kernel/power/hibernate.c:create_image() before disabling irq. And call the counter-part swsusp_arch_suspend_post() at the end. Make weak-link dummy functions for these, so that the arch-specific code can be bound as opt-in.

Thanks for your idea that it makes sense. -- You are receiving this mail because: You are on the CC list for the bug.