Re: [linux-pm] [RFC][PATCH -mm 1/5] PM: Make freeze_processes SMP-safe

Alan Stern
2006-11-30T22:34:05Z

On Thu, 30 Nov 2006, Rafael J. Wysocki wrote:

> > > On the other hand, a stopped process might be waiting for a signal that
> > > can be sent by an unfreezable process -- and the stopped process might be
> > > holding a lock which is needed by some other unfreezable process, so you
> > > need to allow it to run long enough to release the lock before freezing
> > > it.
> >
> > Theoretically, yes. But does it happen? Moreover, even if it does, why can't
> > we hold the unfreezeable process until the lock is released?
> >
> > > Unless you can somehow rule out this scenario (unfreezable process waiting
> > > for resource held by unfrozen but stopped and freezable process), I don't
> > > see how this approach can be made to work.
>
> Hm, in fact I think that if it happens, then this is a bug.
>
> Namely, the freezeable task can only acquire the lock when it's running. Thus
> it would have to acquire the lock before it's stopped. Consequently, it could
> be preempted and subsequently frozen after it has acquired the lock and
> _before_ it's stopped.
>
> Now from the unfreezeable task's point of view it doesn't matter if the
> freezeable task acquired the lock and has been frozen before being stopped
> or if it acquired the lock and was stopped and then has been woken up and
> frozen, since in both cases the final outcome is the same: the freezeable task
> is frozen and holds the lock, so the unfreezeable task cannot continue
> running.
>
> Thus I think the question is if _any_ freezeable task, be it stopped or not,
> can hold a lock that's needed by an unfreezeable task, and I think the answer
> is, generally, 'no, it can't', because otherwise it might block the
> unfreezeable task (if it's frozen while holding the lock).

Well, certainly the answer is "It shouldn't". :-)

I don't know any examples where an unfreezable task waits for a resource
which might be held by a frozen task, PROVIDED that tasks don't get frozen
at a bad spot.

Here's what I mean. usb-storage's kernel thread is unfreezable, because
it might be needed for reading or writing a memory image to a swap region.
If there's an I/O error then usb-storage will try to issue a USB port
reset, for which it needs to acquire the USB device's lock.

Now various other tasks may acquire that lock, and they may even stop
while holding it. However they should never get frozen while holding the
lock -- which means they shouldn't get frozen at arbitrary times merely
because they are stopped. They are careful to call try_to_freeze() only
at times when they don't hold any locks.

Alan Stern