summaryrefslogtreecommitdiffstats
path: root/lib/hexdump.c
diff options
context:
space:
mode:
authorTheodore Ts'o <tytso@mit.edu>2013-04-04 04:02:52 +0200
committerTheodore Ts'o <tytso@mit.edu>2013-04-04 04:02:52 +0200
commitd76a3a77113db020d9bb1e894822869410450bd9 (patch)
tree3e73e273fd8c8e09b2bb87417615d391491eb38e /lib/hexdump.c
parentext4: add might_sleep() annotations (diff)
downloadlinux-d76a3a77113db020d9bb1e894822869410450bd9.tar.xz
linux-d76a3a77113db020d9bb1e894822869410450bd9.zip
ext4/jbd2: don't wait (forever) for stale tid caused by wraparound
In the case where an inode has a very stale transaction id (tid) in i_datasync_tid or i_sync_tid, it's possible that after a very large (2**31) number of transactions, that the tid number space might wrap, causing tid_geq()'s calculations to fail. Commit deeeaf13 "jbd2: fix fsync() tid wraparound bug", later modified by commit e7b04ac0 "jbd2: don't wake kjournald unnecessarily", attempted to fix this problem, but it only avoided kjournald spinning forever by fixing the logic in jbd2_log_start_commit(). Unfortunately, in the codepaths in fs/ext4/fsync.c and fs/ext4/inode.c that might call jbd2_log_start_commit() with a stale tid, those functions will subsequently call jbd2_log_wait_commit() with the same stale tid, and then wait for a very long time. To fix this, we replace the calls to jbd2_log_start_commit() and jbd2_log_wait_commit() with a call to a new function, jbd2_complete_transaction(), which will correctly handle stale tid's. As a bonus, jbd2_complete_transaction() will avoid locking j_state_lock for writing unless a commit needs to be started. This should have a small (but probably not measurable) improvement for ext4's scalability. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> Reported-by: Ben Hutchings <ben@decadent.org.uk> Reported-by: George Barnett <gbarnett@atlassian.com> Cc: stable@vger.kernel.org
Diffstat (limited to 'lib/hexdump.c')
0 files changed, 0 insertions, 0 deletions