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

Rafael J. Wysocki
2006-11-30T22:57:35Z

On Thursday, 30 November 2006 23:34, Alan Stern wrote:
> 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.

This means they are kernel threads, so they won't be entering
get_signal_to_deliver(), will they?

If they don't enter get_signal_to_deliver(), they can only be frozen where
they explicitly call try_to_freeze().

Greetings,
Rafael