aboutsummaryrefslogtreecommitdiffstats
path: root/fs/proc/generic.c
diff options
context:
space:
mode:
authorJan Kara <[email protected]>2007-12-05 07:45:27 +0000
committerLinus Torvalds <[email protected]>2007-12-05 17:21:20 +0000
commitd4beaf4ab5f89496f2bcf67db62ad95d99bfeff6 (patch)
treeae6d005199017e9a0ade169fd69cb73d6c0ac88f /fs/proc/generic.c
parentmm: fix XIP file writes (diff)
downloadkernel-d4beaf4ab5f89496f2bcf67db62ad95d99bfeff6.tar.gz
kernel-d4beaf4ab5f89496f2bcf67db62ad95d99bfeff6.zip
jbd: Fix assertion failure in fs/jbd/checkpoint.c
Before we start committing a transaction, we call __journal_clean_checkpoint_list() to cleanup transaction's written-back buffers. If this call happens to remove all of them (and there were already some buffers), __journal_remove_checkpoint() will decide to free the transaction because it isn't (yet) a committing transaction and soon we fail some assertion - the transaction really isn't ready to be freed :). We change the check in __journal_remove_checkpoint() to free only a transaction in T_FINISHED state. The locking there is subtle though (as everywhere in JBD ;(). We use j_list_lock to protect the check and a subsequent call to __journal_drop_transaction() and do the same in the end of journal_commit_transaction() which is the only place where a transaction can get to T_FINISHED state. Probably I'm too paranoid here and such locking is not really necessary - checkpoint lists are processed only from log_do_checkpoint() where a transaction must be already committed to be processed or from __journal_clean_checkpoint_list() where kjournald itself calls it and thus transaction cannot change state either. Better be safe if something changes in future... Signed-off-by: Jan Kara <[email protected]> Cc: <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
Diffstat (limited to 'fs/proc/generic.c')
0 files changed, 0 insertions, 0 deletions