Comment # 22 on bug 1051059 from Joey Lee

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.