Ok, the above seems to be the culprit here.
Note how the thing is in TASK_INTERRUPTIBLE (S) sleep somewhere in the
reiserfs code..
Debugging this is slightly harder than I'd like, because the "call trace"
is really not a trace, but actually just a dump of the stack of everything
that looks like a kernel address. And a lot of it is crap - stuff left
over by previous calls that hasn't gotten overwritten and is visible
because some function has a large stack footprint (lots of local variables
that end up not being very used and let things show through).
Anyway, what I _think_ is the cleaned-up stacktrace is
[reiserfs_get_block+158/3408]
[reiserfs_readpage+15/20]
[read_cluster_nonblocking+258/324]
[filemap_nopage+332/1032]
[do_no_page+77/192]
[handle_mm_fault+232/340]
[do_page_fault+312/1020]
[error_code+52/64]
[__generic_copy_from_user+52/60]
[opost_block+67/384]
[handle_mm_fault+232/340]
[add_wait_queue+59/68]
[write_chan+365/516]
[tty_write+341/448]
[write_chan+0/516]
[sys_write+143/196]
[system_call+62/80]
and what is interesting is that you got a page fault while you were
copying stuff in to the tty layer. Which happens with TASK_INTERRUPTIBLE
sleep. Now, the page fault code never clears that, so we enter reiserfs
still "sleeping", and reiserfs will do a
if (need_resched(current))
schedule();
which won't do what reiserfs _wants_ it to do at all. Because if
task->state is TASK_INTERRUPTIBLE, the above will go to sleep, not just
cause a nice reschedule. And we'll be sleeping with the task MM semaphore
held - only to wake up if somebody were to signal us or something.
If you can re-create this hang, could you please try to add this single
line to the top of "handle_mm_fault()" in mm/memory.c (after the variable
declarations, of course):
current->state = TASK_RUNNING;
which just means that if we get a page fault while we're half asleep, it
will be safe to do a schedule() without explicitly setting the process
running again.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/