KCSAN in fuse (fuse_request_end <-> fuse_request_end)

KCSAN in fuse (fuse_request_end <-> fuse_request_end)

[Breno Leitao]

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")

Re: KCSAN in fuse (fuse_request_end <-> fuse_request_end)

[Miklos Szeredi]

On Fri, 26 Apr 2024 at 18:18, Breno Leitao <leitao@debian.org> wrote:

> 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?

Probably not necessary.  Does wrapping that access in READ_ONCE() fix
the complaint?

Thanks,
Miklos

Re: KCSAN in fuse (fuse_request_end <-> fuse_request_end)

[Breno Leitao]

On Mon, Apr 29, 2024 at 04:18:56PM +0200, Miklos Szeredi wrote:
> On Fri, 26 Apr 2024 at 18:18, Breno Leitao <leitao@debian.org> wrote:
> 
> > 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?
> 
> Probably not necessary.  Does wrapping that access in READ_ONCE() fix
> the complaint?

Yes, reading ->num_background using READ_ONCE() in the fuse_readahead()
path fix KCSAN complaint.

Should I sent it for review?

Thanks