From: Breno Leitao <leitao@debian.org>
To: miklos@szeredi.hu
Cc: linux-fsdevel@vger.kernel.org
Subject: KCSAN in fuse (fuse_request_end <-> fuse_request_end)
Date: Fri, 26 Apr 2024 09:17:17 -0700 [thread overview]
Message-ID: <ZivTjbq+bLypnkPc@gmail.com> (raw)
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")
next reply other threads:[~2024-04-26 16:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-26 16:17 Breno Leitao [this message]
2024-04-29 14:18 ` KCSAN in fuse (fuse_request_end <-> fuse_request_end) Miklos Szeredi
2024-04-29 17:34 ` Breno Leitao
2024-05-09 11:10 ` Miklos Szeredi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZivTjbq+bLypnkPc@gmail.com \
--to=leitao@debian.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=miklos@szeredi.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).