Hello! This is an experimental automated report about issues detected by Coverity from a scan of next-20191108 as part of the linux-next weekly scan project: https://scan.coverity.com/projects/linux-next-weekly-scan You're getting this email because you were associated with the identified lines of code (noted below) that were touched by recent commits: 303a8f2afc7b ("jbd2: remove the second argument of k[un]map_atomic()") Coverity reported the following: *** CID 1487840: Concurrent data access violations (ATOMICITY) /fs/jbd2/journal.c: 421 in jbd2_journal_write_metadata_buffer() 415 if (jh_in->b_frozen_data) { 416 jbd2_free(tmp, bh_in->b_size); 417 goto repeat; 418 } 419 420 jh_in->b_frozen_data = tmp; vvv CID 1487840: Concurrent data access violations (ATOMICITY) vvv Using an unreliable value of "new_page" inside the second locked section. If the data that "new_page" depends on was changed by another thread, this use might be incorrect. 421 mapped_data = kmap_atomic(new_page); 422 memcpy(tmp, mapped_data + new_offset, bh_in->b_size); 423 kunmap_atomic(mapped_data); 424 425 new_page = virt_to_page(tmp); 426 new_offset = offset_in_page(tmp); If this is a false positive, please let us know so we can mark it as such, or teach the Coverity rules to be smarter. If not, please make sure fixes get into linux-next. :) For patches fixing this, please include these lines (but double-check the "Fixes" first): Reported-by: coverity-bot <keescook+coverity-bot@xxxxxxxxxxxx> Addresses-Coverity-ID: 1487840 ("Concurrent data access violations") Fixes: 303a8f2afc7b ("jbd2: remove the second argument of k[un]map_atomic()") Thanks for your attention! -- Coverity-bot
