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
