forked from luck/tmp_suning_uos_patched
ext4: annotate data race in start_this_handle()
commit 3b1833e92baba135923af4a07e73fe6e54be5a2f upstream. Access to journal->j_running_transaction is not protected by appropriate lock and thus is racy. We are well aware of that and the code handles the race properly. Just add a comment and data_race() annotation. Cc: stable@kernel.org Reported-by: syzbot+30774a6acf6a2cf6d535@syzkaller.appspotmail.com Signed-off-by: Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20210406161804.20150-1-jack@suse.cz Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
parent
a27aad3217
commit
9aca313726
|
@ -349,7 +349,12 @@ static int start_this_handle(journal_t *journal, handle_t *handle,
|
|||
}
|
||||
|
||||
alloc_transaction:
|
||||
if (!journal->j_running_transaction) {
|
||||
/*
|
||||
* This check is racy but it is just an optimization of allocating new
|
||||
* transaction early if there are high chances we'll need it. If we
|
||||
* guess wrong, we'll retry or free unused transaction.
|
||||
*/
|
||||
if (!data_race(journal->j_running_transaction)) {
|
||||
/*
|
||||
* If __GFP_FS is not present, then we may be being called from
|
||||
* inside the fs writeback layer, so we MUST NOT fail.
|
||||
|
|
Loading…
Reference in New Issue
Block a user