Messages in this thread | | | From | "Rafael J. Wysocki" <> | Subject | Re: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8) | Date | Thu, 3 Jun 2010 00:15:32 +0200 |
| |
On Thursday 03 June 2010, Neil Brown wrote: > On Wed, 2 Jun 2010 22:41:14 +0200 > "Rafael J. Wysocki" <rjw@sisk.pl> wrote: > > > On Wednesday 02 June 2010, Neil Brown wrote: > > > - Would this fix the "bug"?? > > > - and address the issues that suspend-blockers was created to address? > > > - or are the requirements on user-space too onerous? > > > > In theory wakeup events can also happen after wait_for_blockers() has returned > > 0 and I guess we should rollback the suspend in such cases. > > > > I naively assumed this was already the case, but on a slightly closer look at > the code it seems not. > > Presumably there is some point deep in the suspend code, probably after the > call to sysdev_suspend, where interrupts are disabled and we are about to > actually suspend. At that point a simple "is a roll-back required" test > could abort the suspend.
Yes.
> Then any driver that handles wake-up events, if it gets and event that (would > normally cause a wakeup) PM_SUSPEND_PREPARE and PM_POST_SUSPEND, could set > the "roll-back is required" flag.
That's my idea, but instead of setting a flag, I'd use a counter increased every time there is a wakeup event. Then, the core suspend core code would store a pre-suspend value of the counter and compare it with the current value after all wakeup event sources had been set. If they were different, the suspend would be aborted.
Rafael
| |