lkml.org 
[lkml]   [2010]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH] - race-free suspend. Was: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)
    Date
    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


    \
     
     \ /
      Last update: 2010-06-03 00:17    [W:2.771 / U:0.100 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site