[lkml]   [2008]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] PM: Acquire device locks on suspend
    On Mon, 7 Jan 2008, Rafael J. Wysocki wrote:

    > > > Do you mean it might have been released already by another thread
    > > > calling device_pm_destroy_suspended() on the same device?
    > >
    > > I was thinking that it might be called before lock_all_devices().
    > I've added pm_sleep_start_end_mtx and the locking dance in
    > device_pm_destroy_suspended() specifically to prevent this from happening.

    Yes, I see. What about the fact that device_suspend() locks
    pm_sleep_start_end_mtx first and pm_sleep_rwsem second, whereas
    device_pm_destroy_suspended() locks pm_sleep_start_end_mtx while
    holding pm_sleep_rwsem? That should produce a lockdep warning.

    > > However let's ignore that possibility and simplify the discussion by
    > > assuming that destroy_suspended_device() is never called except by a
    > > suspend or resume method for that device or one of its ancestors.
    > It may also be called by one of the CPU hotplug notifiers.

    This suggests another approach, simpler but not as general. So far all
    the problems we've seen have been associated with those CPU notifiers.
    Suppose the notifications about CPUs that failed to come back up were
    delayed until after the resume was complete? Drivers like msr would
    then have to check in their resume handler whether the CPU was actually
    up, but no other changes would be needed.

    In this way we could fix the immediate problem. It wouldn't help with
    other sorts of devices that need to be unregistered during a suspend,

    > Okay, well, now I'm leaning towards the asynchronous approach.
    > I'll prepare a new patch and send it later today.


    Alan Stern

     \ /
      Last update: 2008-01-07 22:35    [W:0.019 / U:7.764 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site