On Tue, Aug 29, 2023 at 07:57PM +0900, Dominique Martinet wrote: [...] > Yes well that doesn't seem too hard to hit, both threads are just > setting O_NONBLOCK to the same fd in parallel (0x800 is 04000, > O_NONBLOCK) > > I'm not quite sure why that'd be a problem; and I'm also pretty sure > that wouldn't work anyway (9p has no muxing or anything that'd allow > sharing the same fd between multiple mounts) > > Can this be flagged "don't care" ? If it's an intentional data race, it could be marked data_race() [1]. However, staring at this code for a bit, I wonder why the f_flags are set on open, and not on initialization somewhere... [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/access-marking.txt Anyway, a patch like the below would document that the data race is intended and we assume that there is no way (famous last words) the compiler or the CPU can mess it up (and KCSAN won't report it again). ------ >8 ------ From: Marco Elver <elver@xxxxxxxxxx> Date: Tue, 29 Aug 2023 15:48:58 +0200 Subject: [PATCH] 9p: Annotate data-racy writes to file::f_flags syzbot reported: | BUG: KCSAN: data-race in p9_fd_create / p9_fd_create | | read-write to 0xffff888130fb3d48 of 4 bytes by task 15599 on cpu 0: | p9_fd_open net/9p/trans_fd.c:842 [inline] | p9_fd_create+0x210/0x250 net/9p/trans_fd.c:1092 | p9_client_create+0x595/0xa70 net/9p/client.c:1010 | v9fs_session_init+0xf9/0xd90 fs/9p/v9fs.c:410 | v9fs_mount+0x69/0x630 fs/9p/vfs_super.c:123 | legacy_get_tree+0x74/0xd0 fs/fs_context.c:611 | vfs_get_tree+0x51/0x190 fs/super.c:1519 | do_new_mount+0x203/0x660 fs/namespace.c:3335 | path_mount+0x496/0xb30 fs/namespace.c:3662 | do_mount fs/namespace.c:3675 [inline] | __do_sys_mount fs/namespace.c:3884 [inline] | [...] | | read-write to 0xffff888130fb3d48 of 4 bytes by task 15563 on cpu 1: | p9_fd_open net/9p/trans_fd.c:842 [inline] | p9_fd_create+0x210/0x250 net/9p/trans_fd.c:1092 | p9_client_create+0x595/0xa70 net/9p/client.c:1010 | v9fs_session_init+0xf9/0xd90 fs/9p/v9fs.c:410 | v9fs_mount+0x69/0x630 fs/9p/vfs_super.c:123 | legacy_get_tree+0x74/0xd0 fs/fs_context.c:611 | vfs_get_tree+0x51/0x190 fs/super.c:1519 | do_new_mount+0x203/0x660 fs/namespace.c:3335 | path_mount+0x496/0xb30 fs/namespace.c:3662 | do_mount fs/namespace.c:3675 [inline] | __do_sys_mount fs/namespace.c:3884 [inline] | [...] | | value changed: 0x00008002 -> 0x00008802 Within p9_fd_open(), O_NONBLOCK is added to f_flags of the read and write files. This may happen concurrently if e.g. 2 tasks mount the same filesystem. Mark the plain read-modify-writes as intentional data-races, with the assumption that the result of executing the accesses concurrently will always result in the same result despite the accesses themselves not being atomic. Reported-by: syzbot+e441aeeb422763cc5511@xxxxxxxxxxxxxxxxxxxxxxxxx Signed-off-by: Marco Elver <elver@xxxxxxxxxx> --- net/9p/trans_fd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c index 00b684616e8d..9b01e15a758b 100644 --- a/net/9p/trans_fd.c +++ b/net/9p/trans_fd.c @@ -833,13 +833,13 @@ static int p9_fd_open(struct p9_client *client, int rfd, int wfd) if (!(ts->rd->f_mode & FMODE_READ)) goto out_put_rd; /* prevent workers from hanging on IO when fd is a pipe */ - ts->rd->f_flags |= O_NONBLOCK; + data_race(ts->rd->f_flags |= O_NONBLOCK); ts->wr = fget(wfd); if (!ts->wr) goto out_put_rd; if (!(ts->wr->f_mode & FMODE_WRITE)) goto out_put_wr; - ts->wr->f_flags |= O_NONBLOCK; + data_race(ts->wr->f_flags |= O_NONBLOCK); client->trans = ts; client->status = Connected; -- 2.42.0.rc2.253.gd59a3bf2b4-goog
