Re: [syzbot] [net?] [v9fs?] KCSAN: data-race in p9_fd_create / p9_fd_create (2)
From: Dominique Martinet <asmadeus@codewreck.org>
Date: 2023-08-29 10:59:46
Also in:
linux-fsdevel, lkml, v9fs
syzbot wrote on Tue, Aug 29, 2023 at 02:39:53AM -0700:
================================================================== 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] __se_sys_mount+0x27f/0x2d0 fs/namespace.c:3861 __x64_sys_mount+0x67/0x80 fs/namespace.c:3861 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd 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] __se_sys_mount+0x27f/0x2d0 fs/namespace.c:3861 __x64_sys_mount+0x67/0x80 fs/namespace.c:3861 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x00008002 -> 0x00008802
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" ? -- Dominique Martinet | Asmadeus