Re: kernel BUG at fs/jbd2/transaction.c:1086!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 31 Mar 2011, Jan Kara wrote:

> On Wed 30-03-11 17:32:06, Lukas Czerner wrote:
> > Hello,
> > 
> > I have hit BUG_ON while running xfstest 234 in the loop
> > on the ext4. Backtrace below .
> > 
> > I thought that this problem was solved with
> > 67eeb5685d2a211c0252ac7884142e503c759500 however it is still present.
> > I might be a bit hard to hit, but once you run
> > 
> > while true; do sync; sleep 0.3; done
> > 
> > concurrently it is reproducible almost all the time. I have tried to
> > understand what is going on but only thing I can see is this course
> > of action:
> > 
> > ext4_write_dquot
> >   ext4_journal_start <- h_buffer_credits = 2
> >   dquot_commit
> >     v2_write_dquot
> >       qtree_write_dquot
> >         ext4_quota_write
> >           ext4_handle_dirty_metadata	<- this takes one block reserved
> > 	  				   for journal
> > 					   h_buffer_credits--
> >     v2_write_file_info
> >       ext4_quota_write
> >         ext4_handle_dirty_metadata	<- this takes second block reserved
> > 	  				   for journal
> > 					   h_buffer_credits--
> >   ext4_journal_stop
> > 
> > However apparently I am missing something, because according to the
> > backtrace the second call of jbd2_journal_dirty_metadata() may end up
> > with BUG_ON -> J_ASSERT_JH(jh, handle->h_buffer_credits > 0);
> > 
> > So someone else is touching our handle apparently, but I go not exacly
> > know what is going on. From my simple debugging printk information I
> > have put with before ext4_handle_dirty_metadata() in ext4_quota_write()
> > we can see:
> > 
> > [  226.450263] ext4_quota_write: len 48, off 5136, type 0 h_ref 1
> > credits 2
> > [  226.458950] ext4_quota_write: len 24, off 8, type 0 h_ref 1 credits 0
> > 
> > It is clear someone changed handle between v2_write_dquot() and
> > v2_write_file_info() does anyone have idea what is going on ?
>   It's simpler than that I believe. ext4_write_dquot() does also
>         inode->i_mtime = inode->i_ctime = CURRENT_TIME;
>         ext4_mark_inode_dirty(handle, inode);
> and that eats another credit. Looking at the comment before
> EXT4_QUOTA_TRANS_BLOCKS, we in fact counted with inode and data update but
> didn't count with the info update. It's actually a race that we ended up
> doing info update in our transaction - someone marked info dirty and before
> he managed to write it, we went in, saw the dirty flag and wrote it for
> him. So the attached patch should fix the problem for you.
> 
> 									Honza
> 

The patch fixes the problem, you can add

Reported-and-tested-by: Lukas Czerner <lczerner@xxxxxxxxxx>

Ted, could you pick this up ASAP ? Also I think this needs to go into
stable as well.

Thanks!
-Lukas
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux