Hello,
I am running Linus' upstream kernel[1] with KCSAN enabled, and KCSAN
complains about a possible data race condition in fuse.
BUG: KCSAN: data-race in fuse_readahead [fuse] / fuse_request_end [fuse]
read-write to 0xffff8883a6666598 of 4 bytes by task 113809 on cpu 39:
fuse_request_end (fs/fuse/dev.c:318) fuse
fuse_dev_do_write (fs/fuse/dev.c:?) fuse
fuse_dev_write (fs/fuse/dev.c:?) fuse
do_iter_readv_writev (fs/read_write.c:742)
vfs_writev (fs/read_write.c:971)
do_writev (fs/read_write.c:1018)
__x64_sys_writev (fs/read_write.c:1088)
x64_sys_call (arch/x86/entry/syscall_64.c:33)
do_syscall_64 (arch/x86/entry/common.c:?)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
read to 0xffff8883a6666598 of 4 bytes by task 113787 on cpu 8:
fuse_readahead (fs/fuse/file.c:1005) fuse
read_pages (mm/readahead.c:166)
page_cache_ra_unbounded (mm/readahead.c:?)
page_cache_ra_order (mm/readahead.c:540)
ondemand_readahead (mm/readahead.c:662)
page_cache_sync_ra (mm/readahead.c:689)
filemap_get_pages (mm/filemap.c:2507)
filemap_read (mm/filemap.c:2601)
generic_file_read_iter (mm/filemap.c:?)
fuse_file_read_iter (fs/fuse/file.c:? fs/fuse/file.c:1709) fuse
vfs_read (fs/read_write.c:396 fs/read_write.c:476)
value changed: 0x00000001 -> 0x00000000
Looking at the code, this happens when two parallel data pathes touch
fuse_conn->num_background potentially at the same time.
fuse_request_end() reads and writes to ->num_background while holding
the bg_lock, but fuse_readahead() does not hold any lock before reading
->num_background. That is what KCSAN seems to be complaining about.
Should we get ->bg_lock before reading ->num_background?
Thanks!
[1] 13a2e429f644 ("Merge tag 'perf-tools-fixes-for-v6.9-2024-04-19' of git://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools")
