> > On Thu, Mar 03, 2005 at 02:10:04PM +0100, Jan Kara wrote: <snip> > > It died because of dereferencing RBP which contained memory poisoning > > signature: > > > > 0xffffffff801d9996 <log_do_checkpoint+246>: lock btsl $0x13,0x0(%rbp) > > > > apparently x86-64 generates #SS for %rbp non-canonical addresses too, like > > i386 does with %ebp segment overruns. > > > > Crash occured in bit_spin_trylock called by jbd_trylock_bh_state from > > log_do_checkpoint (fs/jbd/checkpoint.c:636), because jh2bh (jh->b_bh) > > returned poisoned pattern - apparently somebody else freed journal_head > > while we were holding pointer to it. No idea how it happened. > > > > > Anyway I was briefly reading the code in log_do_checkpoint() and two > > > things are not clear to me - are we guaranteed that > > > transaction->t_checkpoint_list is non-empty (the code relies on that)? > > > Another thing is - __flush_buffer() can sleep. Cannot someone change > > > the t_checkpoint_list while we are sleeping? We are protected only by > > > the j_checkpoint_sem and that only protects us against other > > > log_do_checkpoint() calls. > > > > Code apparently believes that if __flush_buffer() sleeps then it returns > > 1. > Yes, I see that all the buffer heads will be processed. But I'm not > sure whether someone cannot come while we are sleeping and release the > journal_head next_jh points too (actually it seems that such thing is > happening). I'll have a look what could cause such nasty thing... Sorry, you were right that the test with 'retry' should handle this case also correctly. It must be something else.
Honza <snip> -- Jan Kara <[EMAIL PROTECTED]> SuSE CR Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/