aboutsummaryrefslogtreecommitdiffstats
path: root/fs/btrfs/volumes.c
diff options
context:
space:
mode:
authorTheodore Ts'o <tytso@mit.edu>2011-02-12 08:18:24 -0500
committerTheodore Ts'o <tytso@mit.edu>2011-02-12 08:18:24 -0500
commite44718318004a5618d1dfe2d080e2862532d8e5f (patch)
treec1a6af07da3184f5785a62062510ac8e86b8050a /fs/btrfs/volumes.c
parente9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d (diff)
downloadkernel_samsung_smdk4412-e44718318004a5618d1dfe2d080e2862532d8e5f.zip
kernel_samsung_smdk4412-e44718318004a5618d1dfe2d080e2862532d8e5f.tar.gz
kernel_samsung_smdk4412-e44718318004a5618d1dfe2d080e2862532d8e5f.tar.bz2
jbd2: call __jbd2_log_start_commit with j_state_lock write locked
On an SMP ARM system running ext4, I've received a report that the first J_ASSERT in jbd2_journal_commit_transaction has been triggering: J_ASSERT(journal->j_running_transaction != NULL); While investigating possible causes for this problem, I noticed that __jbd2_log_start_commit() is getting called with j_state_lock only read-locked, in spite of the fact that it's possible for it might j_commit_request. Fix this by grabbing the necessary information so we can test to see if we need to start a new transaction before dropping the read lock, and then calling jbd2_log_start_commit() which will grab the write lock. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Diffstat (limited to 'fs/btrfs/volumes.c')
0 files changed, 0 insertions, 0 deletions