diff options
author | Theodore Ts'o <tytso@mit.edu> | 2011-02-12 08:18:24 -0500 |
---|---|---|
committer | Theodore Ts'o <tytso@mit.edu> | 2011-02-12 08:18:24 -0500 |
commit | e44718318004a5618d1dfe2d080e2862532d8e5f (patch) | |
tree | c1a6af07da3184f5785a62062510ac8e86b8050a /fs/fscache | |
parent | e9e3bcecf44c04b9e6b505fd8e2eb9cea58fb94d (diff) | |
download | kernel_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/fscache')
0 files changed, 0 insertions, 0 deletions