Thanks for the report Hao! I think following lines in fast_commit.c
are the culprit:
if (likely(sbi->s_fc_avg_commit_time))
sbi->s_fc_avg_commit_time = (commit_time +
sbi->s_fc_avg_commit_time * 3) / 4;
else
sbi->s_fc_avg_commit_time = commit_time;
This should have been done after taking sbi level lock, but this is
happening after releasing the lock.
I'll send a patch to fix this, thanks again!
- Harshad
On Sun, Apr 4, 2021 at 2:52 AM Hao Sun <sunhao.th@xxxxxxxxx> wrote:
>
> Hi:
>
> When using Healer(https://github.com/SunHao-0/healer/tree/dev) to fuzz
> the Linux kernel, I found a data-race vulnerability in ext4_fc_commit
> / ext4_fc_commit, which looks strange.
> Sorry, data-race is usually difficult to reproduce. I cannot provide
> you with a reproducing program.
> I hope that the call stack information in the crash log can help you
> locate the problem.
> Kernel config and full log can be found in the attachment.
>
> Here is the detailed information:
> commit: 3b9cdafb5358eb9f3790de2f728f765fef100731
> version: linux 5.11
> git tree: upstream
> report:
> ==================================================================
> BUG: KCSAN: data-race in ext4_fc_commit / ext4_fc_commit
> write to 0xffff88800dd89f10 of 8 bytes by task 12063 on cpu 0:
> ext4_fc_commit+0x1e6/0x1850 linux/fs/ext4/fast_commit.c:1205
> ext4_fsync_journal linux/fs/ext4/fsync.c:115 [inline]
> ext4_sync_file+0x38c/0x6d0 linux/fs/ext4/fsync.c:174
> vfs_fsync_range linux/fs/sync.c:200 [inline]
> vfs_fsync linux/fs/sync.c:214 [inline]
> do_fsync linux/fs/sync.c:224 [inline]
> __do_sys_fdatasync linux/fs/sync.c:237 [inline]
> __se_sys_fdatasync linux/fs/sync.c:235 [inline]
> __x64_sys_fdatasync+0x7a/0xd0 linux/fs/sync.c:235
> do_syscall_64+0x39/0x80 linux/arch/x86/entry/common.c:46
> entry_SYSCALL_64_after_hwframe+0x44/0xae
