et_signal_to_deliver() ever called at any time other than when the CPU
is about to switch back into user mode? If not then there shouldn't be
any problem. The routines I was talking about earlier hold the USB device
locks while running in
't reset the device.
Still, you would have your work cut out trying to find all the places in
the kernel where an unfreezable process takes a lock which might be held
by a user process. For instance, I doubt that all the wor
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
> > > > i
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?
Alan Stern
wap 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
ck before freezing
it.
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.
Alan Stern
risk (except of course when the hard disks have failed).
It sounds like you're saying that nothing is safe except restarting
(either resume or reboot) on the original failed system. So that's your
answer -- the only safe approach is to fix the computer and restart it.
Alan Stern
---
read() does not include its own memory barrier. If you want one,
you have to write it yourself. At least, that's how I interpret
Documentation/atomic_ops.txt.
Alan Stern
-
Take Surveys. Earn Cash. Influence the Future
