Zygo Blaxell wrote:
> ...and I greatly appreciate your efforts so far. It's interesting that
> your first patch worked as well as it did (at least for lockups...I haven't
> run any speed tests on it).
OK, processes stuck in 'D' state problem has been solved in loop-AES-v1.7b
Here is what happened: VM in some rare occasions called loop driver
make_request function with process state set to TASK_UNINTERRUPTIBLE when it
should have been set to TASK_RUNNING. Loop driver then called function that
had code like this:
if(current->need_resched)
schedule();
Above code provides low latency scheduling by calling schedule() when
scheduler has indicated that a process should give up control of CPU. Guess
what happens when schedule() is called with process state set to
TASK_UNINTERRUPTIBLE and no-one to wake up the process... process would
deadlock until it received some signal that would wake it up.
It is pretty crappy for VM to do that, but it is also unacceptable for loop
driver to not handle that kind of crap correctly. Fix is to add
"set_current_state(TASK_RUNNING);" to beginning of loop_make_request().
Other elevator bugs fixed in fix-pausing-2h patch posted earlier are also
real bugs, but they weren't responsible for these deadlocks.
Like I said above, this bug is fixed in loop-AES-v1.7b. Below is one line
fix for older kernel patch versions. I have CC'd some people who may be
interested in merging this fix to code they maintain.
--- linux-2.4.21-pre4-AES/drivers/block/loop.c.old Thu Jan 30 11:59:54 2003
+++ linux-2.4.21-pre4-AES/drivers/block/loop.c Thu Jan 30 12:00:37 2003
@@ -600,6 +600,7 @@
struct buffer_head *bh;
struct loop_device *lo;
+ set_current_state(TASK_RUNNING);
if (!buffer_locked(rbh))
BUG();
Regards,
Jari Ruusu <jari.ruusu@pp.inet.fi>
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
