kernel-ark/fs/jbd
Jan Kara 09e05d4805 jbd: Fix assertion failure in commit code due to lacking transaction credits
ext3 users of data=journal mode with blocksize < pagesize were occasionally
hitting assertion failure in journal_commit_transaction() checking whether the
transaction has at least as many credits reserved as buffers attached.  The
core of the problem is that when a file gets truncated, buffers that still need
checkpointing or that are attached to the committing transaction are left with
buffer_mapped set. When this happens to buffers beyond i_size attached to a
page stradding i_size, subsequent write extending the file will see these
buffers and as they are mapped (but underlying blocks were freed) things go
awry from here.

The assertion failure just coincidentally (and in this case luckily as we would
start corrupting filesystem) triggers due to journal_head not being properly
cleaned up as well.

Under some rare circumstances this bug could even hit data=ordered mode users.
There the assertion won't trigger and we would end up corrupting the
filesystem.

We fix the problem by unmapping buffers if possible (in lots of cases we just
need a buffer attached to a transaction as a place holder but it must not be
written out anyway). And in one case, we just have to bite the bullet and wait
for transaction commit to finish.

Reviewed-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Jan Kara <jack@suse.cz>
2012-09-12 15:52:03 +02:00
..
checkpoint.c jbd: Write journal superblock with WRITE_FUA after checkpointing 2012-05-15 23:34:37 +02:00
commit.c jbd: Fix assertion failure in commit code due to lacking transaction credits 2012-09-12 15:52:03 +02:00
journal.c jbd: don't write superblock when unmounting an ro filesystem 2012-08-15 13:53:30 +02:00
Kconfig
Makefile
recovery.c jbd: Check return value of blkdev_issue_flush() 2012-07-09 23:38:36 +02:00
revoke.c jbd: clear revoked flag on buffers before a new transaction started 2011-11-22 01:20:53 +01:00
transaction.c jbd: Fix assertion failure in commit code due to lacking transaction credits 2012-09-12 15:52:03 +02:00