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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 11 Aug 2011 09:32:22 -0400
From:	Josef Bacik <>
To:	Ext4 Developers List <>
CC:	Jan Kara <>
Subject: Can a metadata buffer end up in journal_unmap_buffer?


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.

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.

The problem is I don't think we can call journal_unmap_buffer() on just
a normal metadata block (that is with data=ordered), it only gets called
by ext3_invalidatepage() which is only called on pages on the inodes
address space, so not metadata.  However, Jan had a patch to delay the
free'ing of buffers for orphan reasons, with commit


which makes it seem like metadata can come through
journal_unmap_buffer()?  Does anybody know for sure one way or the
other?  And if you happen to have a theory on the actual problem itself
I would _love_ to hear it :).  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