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

Alan Stern
2006-12-01T21:17:07Z

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