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. Alan Stern
