Re: [PATCH 1/8] PM: Add suspend block api.

["Arve Hjønnevåg" <arve@android.com>]

On Thu, May 6, 2010 at 12:40 PM, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Thu, 6 May 2010, Rafael J. Wysocki wrote:
>
>> > Here's a completely new issue.  When using opportunistic suspends on an
>> > SMP system, it could happen that the system gets a wakeup event and
>> > this routine starts running again before the event's IRQ handler has
>> > finished (or has enabled a suspend blocker).  The system would
>> > re-suspend too soon.
>>
>> This routine will be run from a freezable workqueue.
>
> But how do you know that processes won't get unfrozen until all the
> pending IRQs have been handled?  Imagine something like this:
>
>        CPU 0                   CPU 1
>        -----                   -----
>        Wake up non-boot CPUs
>        Resume devices          Invoke the IRQ handler
>
>        [ CPU 0 should wait here for the handler to finish,
>          but it doesn't ]
>
>        Defrost threads         Handler running...
>        Workqueue routine runs
>        Start another suspend
>                                Handler enables a suspend blocker,
>                                but it's too late

It is not optimal, but it is not too late. We check if any suspend
blockers block suspend after disabling non-boot cpus so as long as
this is done in a way that does not lose interrupts the resuspend
attempt will not succeed.

-- 
Arve Hjønnevåg