On Thu, May 6, 2010 at 12:40 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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 _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
