Messages in this thread | | | Subject | soft deadlock in blk_congestion_wait (2.6.7) | From | Miklos Szeredi <> | Date | Thu, 08 Jul 2004 11:31:30 +0200 |
| |
While running LTP tests (more specifically the ftest* testcases) on FUSE (http://sourceforge.net/projects/avf), I run into the following problem: the process serving the FUSE filesystem requests does some debugging write to an ext3 filesystem, and deadlocks in blk_congestion_wait:
fusexmp D C043E760 0 2130 2125 (NOTLB) c0c99c50 00200082 c09bb3f0 c043e760 00000664 c791f6b0 c043ec08 00000000 c0c99c64 c0c99c50 00200246 00000801 f70d3b39 00000664 c09bb598 0066663b c0c99c64 c03ce968 c0c99c8c c033195e c0c99c64 0066663b c0115051 c0443f00 Call Trace: [<c033195e>] schedule_timeout+0x5e/0xb0 [<c03318f1>] io_schedule_timeout+0x11/0x20 [<c02275be>] blk_congestion_wait+0x6e/0x90 [<c01369ce>] balance_dirty_pages+0xde/0x150 [<c01332a4>] generic_file_aio_write_nolock+0x4f4/0xc00 [<c0133ac1>] generic_file_aio_write+0x81/0xa0 [<c018609f>] ext3_file_write+0x3f/0xd0 [<c014eab7>] do_sync_write+0x87/0xc0 [<c014eb9a>] vfs_write+0xaa/0x130 [<c014ecbf>] sys_write+0x3f/0x60 [<c010423b>] syscall_call+0x7/0xb
Some other process performing a read will kick it out of this coma, but if left alone it will wait there forever.
The FUSE request being served is a write, called from aops->commit_write(). So my guess is that the kernel does not handle this sort of recursive write too well.
Can someone explain what blk_congestion_wait() is waiting for, and why does that event not happen?
I've seen a very similar report for CIFS here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=108807439504273&w=2
So it's not even FUSE specific, though it could be a bug in the filesystems themselves in both cases, or possibly a core kernel bug.
Thanks, Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |