diff options
author | Jan Kara <jack@suse.cz> | 2017-04-30 03:12:16 +0300 |
---|---|---|
committer | Theodore Ts'o <tytso@mit.edu> | 2017-04-30 03:12:16 +0300 |
commit | c52c47e4b4fbe4284602fc2ccbfc4a4d8dc05b49 (patch) | |
tree | 4b61b1a2c7c8ff64679d49c191149fcadfb78176 /fs/lockd/procfs.h | |
parent | 80a2ea9f85850f1cdae814be03b4a16c3d3abc00 (diff) | |
download | linux-c52c47e4b4fbe4284602fc2ccbfc4a4d8dc05b49.tar.xz |
jbd2: Fix lockdep splat with generic/270 test
I've hit a lockdep splat with generic/270 test complaining that:
3216.fsstress.b/3533 is trying to acquire lock:
(jbd2_handle){++++..}, at: [<ffffffff813152e0>] jbd2_log_wait_commit+0x0/0x150
but task is already holding lock:
(jbd2_handle){++++..}, at: [<ffffffff8130bd3b>] start_this_handle+0x35b/0x850
The underlying problem is that jbd2_journal_force_commit_nested()
(called from ext4_should_retry_alloc()) may get called while a
transaction handle is started. In such case it takes care to not wait
for commit of the running transaction (which would deadlock) but only
for a commit of a transaction that is already committing (which is safe
as that doesn't wait for any filesystem locks).
In fact there are also other callers of jbd2_log_wait_commit() that take
care to pass tid of a transaction that is already committing and for
those cases, the lockdep instrumentation is too restrictive and leading
to false positive reports. Fix the problem by calling
jbd2_might_wait_for_commit() from jbd2_log_wait_commit() only if the
transaction isn't already committing.
Fixes: 1eaa566d368b214d99cbb973647c1b0b8102a9ae
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Diffstat (limited to 'fs/lockd/procfs.h')
0 files changed, 0 insertions, 0 deletions