Comment # 16 on bug 1051059 from Takashi Iwai

(In reply to Joey Lee from comment #14)
> (In reply to Matwey Kornilov from comment #13)
> > (In reply to Joey Lee from comment #12)
> > > (In reply to Matwey Kornilov from comment #8)
> > > > Every other time the resuming just hard-freezes the whole system when
> > > > showing screen-locker. I think it is related to 1051060.
> > > > When the system survives resuming I see BUG:
> > > 
> > > So, the hibernation is success even you saw the "BUG:" stack dump?
> > >
> > 
> > Yes, I see this stack after successful resuming.
> >  
> > > Base on the code in ___might_sleep(), it should not blocks hibernation. It
> > > just print out the "BUG" message.
> > 
> > So, then we probably can just ignore them, but they look scary enough.
> 
> I agree. 
> 
> I am thinking to create a new system state like SYSTEM_SLEEPING to avoid the
> checking logic in ___might_sleep(). I still need to check the scope and it
> may not accept by upstream.

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.

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.