[lkml]   [2009]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Async resume patch (was: Re: [GIT PULL] PM updates for 2.6.33)
    On Tuesday 08 December 2009, Alan Stern wrote:
    > On Tue, 8 Dec 2009, Rafael J. Wysocki wrote:
    > > Suppose we use rwsem and during suspend each child uses a down_read() on a
    > > parent and then the parent uses down_write() on itself. What if, whatever the
    > > reason, the parent is a bit early and does the down_write() before one of the
    > > children has a chance to do the down_read()? Aren't we toast?
    > >
    > > Do we need any direct protection against that or does it just work itself out
    > > in a way I just don't see right now?
    > That's not the way it should be done. Linus had children taking their
    > parents' locks during suspend, which is simple but leads to
    > difficulties.
    > Instead, the PM core should do a down_write() on each device before
    > starting the device's async suspend routine, and an up_write() when the
    > routine finishes. Parents should, at the start of their async routine,
    > do down_read() on each of their children plus whatever other devices
    > they need to wait for. The core can do the waiting for children part
    > and the driver's suspend routine can handle any other waiting.
    > This is a little more awkward because it requires the parent to iterate
    > through its children.

    I can live with that.

    > But it does solve the off-tree dependency problem for suspends.

    That's a plus, but I still think we're trying to create a barrier-alike
    mechanism using lock.

    There's one more possibility to consider, though. What if we use a completion
    instead of the flag + wait queue? It surely is a standard synchronization
    mechanism and it seems it might work here.


     \ /
      Last update: 2009-12-08 21:33    [W:0.020 / U:63.328 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site