On Thu, 6 May 2010, Arve Hjønnevåg wrote: > 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. Is it possible for the resuspend to disable CPU 1 before the IRQ handler can enable its suspend blocker? (Probably not -- but I don't know enough about how non-boot CPUs are enabled or disabled.) Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
