lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 11 Aug 2011 12:21:25 -0400
From:	Josef Bacik <>
To:	Jan Kara <>
CC:	Ext4 Developers List <>
Subject: Re: Can a metadata buffer end up in journal_unmap_buffer?

On 08/11/2011 12:16 PM, Josef Bacik wrote:
> On 08/11/2011 11:28 AM, Jan Kara wrote:
>>   Hello,
>> On Thu 11-08-11 09:32:22, Josef Bacik wrote:
>>> I have this weird bug that has been plaguing me for a while where
>>> t_outstanding_credits will end up less than t_nr_buffers.  I have done
>>> all sorts of things to try and catch when it happens but nothing seems
>>> to catch it.  At some point I had thought that we were screwing up in
>>> journal_unmap_buffer.  If a buffer is not on a transaction but is still
>>> a part of a checkpoint we will do a journal_file_buffer() onto the
>>> current running transaction's forget list.  The thing is we can still
>>> have b_modified set since we only clear it on
>>> do_get_write_access/journal_get_create_access if it isn't a part of the
>>> transaction yet.  So if we do the journal_file_buffer() before anybody
>>> calls do_get_write_access/journal_get_create_access we will short
>>> circuit these checks and b_modified will never be cleared and so when we
>>> do journal_dirty_metadata we won't account for the new buffer and it
>>> will end up inc'ing t_nr_buffers but not t_outstanding_credits.
>>   Good spotting!
>>> I had thought this was the problem before and put in a jh->b_modified =
>>> 0 in __dispose_buffer, but apparently the problem still happened.  But
>>> that support person/customer were not entirely reliable so I'm back to
>>> thinking this is what happened and they just didn't run with my patch.
>>   Umm, I think there's one more way how buffer b_modified == 1 can get
>> to other transaction's forget list. In journal_unmap_buffer(), transaction
>> == journal->j_committing_transaction case we do set_buffer_freed() and
>> set b_next_transaction to the running transaction. So when the currently
>> committing transaction finishes, it refiles the buffer to BJ_Forget list
>> of the running transaction. b_modified handling seems to be really fragile
>> in this regard. I guess the rule is that whenever we are going to change
>> b_transaction or b_next_transaction, we should clear b_modified.
> Well this is happening on RHEL5, where we have
> set_buffer_freed();
> if (jh->b_next_transaction)
> 	jh->b_next_transaction = NULL;
> so the only way this happens if it goes through __dispose_buffer.
> And the more I look at this I can't see how it would happen exactly.  I
> can definitely get a modified buffer to show up on the forget list, but
> I can't see how I would then re-modify the thing to get it to show up on
> BJ_Metadata.  On data=journal mode I can definitely see how to do it,
> but not with data=ordered mode.  The only way to go through
> journal_unmap_buffer is to truncate the inode, and for a symlink the
> only way to make that happen is to delete it.  So I don't see how I
> could then make it get dirtied again?  Thanks,

Bah ignore me I'm an idiot, if the thing gets evicted from cache it will
call truncate_inode_pages which will do all that work.  I've been
staring at jbd entirely too long :(.  Thanks,

To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists