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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Friday, 1 December 2006 22:17, Alan Stern wrote:
> On Fri, 1 Dec 2006, Rafael J. Wysocki wrote:
> 
> > On Friday, 1 December 2006 15:56, Alan Stern wrote:
> > > On Thu, 30 Nov 2006, Rafael J. Wysocki wrote:
> > > 
> > > > > 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?
> > > 
> > > Some of them are kernel threads and some of them are user threads.  Only 
> > > the kernel threads call try_to_freeze().
> > > 
> > > > If they don't enter get_signal_to_deliver(), they can only be frozen where
> > > > they explicitly call try_to_freeze().
> > > 
> > > What about the user threads?
> > 
> > We send fake signals to them, so they enter get_signal_to_deliver() and they
> > call try_to_freeze() from there.
> 
> Well then, see, you're doing exactly what you said should never happen --
> you are freezing a user thread while it might be holding a lock that the
> unfreezable usb-storage thread needs.

Well, the current code does exactly the same - it freezes userland tasks
by sending them fake signals (and there's no way to check if such a process
holds any locks at that time).  Moreover, it's been doing that from day one
and my patch doesn't change that.

If you have an unfreezeable process that depends on locks that may be held
by userland tasks, then _this_ is a bug, IMHO.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
		R. Buckminster Fuller


[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux