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

["Rafael J. Wysocki" <rjw@sisk.pl>]

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

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV