I'm trying to debug a e2compr-related bug, but I'm afraid I don't know
enough about the buffer locking semantics.
A bit about the problem: with 2.2.14+e2compr-0.4.37, I can reproducibly
deadlock kernel. It takes a rewrite to a largish write and unlink, but I
haven't yet isolated the exact syscall sequence, since I can reproduce it
everytime with samba and MSWord. Smbd process will hang in ext2_truncate
which has been called by ext2_delete_inode (this far I got with kdb.) It
seems that the kernel tries to write the inode back to disk, but the
corresponding bh lock is held by someone and supposedly never released. I
also get "async IO completed on unlocked page" messages to the log, so it
might be that someone releases wrong lock somewhere.
My question is: how do I debug this? I tried adding printk's to
unlock_buffer and lock_buffer calls (*), but as you guess, I got bit too
much information. For what I could deduce from that flood, unlock_buffer
is often called for unlocked buffers (in buffer.c::end_buffer_io_sync()),
but in buffer:.c:end_buffer_io_async() this condition yields the above
mentioned warning. This makes it a bit harder to find the unbalanced
lock-unlock. Since the I guess I'll have to forget about those debugging
gizmos and use the source (Luke), I think I need to understand how and
when those locks are supposed to be locked and released...
As far as I can tell, e2compr patch does not touch
lock_buffer/unlock_buffer calls, so there might be a premature return from
function that has locked the buffer or something....
Sorry that I brought this to l-k, but the response on e2compr-list was
less than enthusiastic...
-- v --
(*) And to some set_bit(BH_Lock, bh) and clear_bit(BH_Lock, bh)
calls (why are those used instead of lock_buffer()? There is even
bh->b_state &= (1 << BH_Lock);
in ll_rw_blk.c.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Apr 23 2000 - 21:00:22 EST