On Fri, 5 Jul 2024 at 08:02, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > On Thu, Jul 4, 2024 at 5:28 PM Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: > > > > On Thu, 4 Jul 2024 at 16:22, syzbot > > <syzbot+701037856c25b143f1ad@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > Hello, > > > > > > syzbot found the following issue on: > > > > > > HEAD commit: 795c58e4c7fc Merge tag 'trace-v6.10-rc6' of git://git.kern.. > > > git tree: upstream > > > console output: https://syzkaller.appspot.com/x/log.txt?x=16a6b6b9980000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=5b9537cd00be479e > > > dashboard link: https://syzkaller.appspot.com/bug?extid=701037856c25b143f1ad > > > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40 > > > > > > Unfortunately, I don't have any reproducer for this issue yet. > > > > > > Downloadable assets: > > > disk image: https://storage.googleapis.com/syzbot-assets/3d1d205c1fdf/disk-795c58e4.raw.xz > > > vmlinux: https://storage.googleapis.com/syzbot-assets/641c78d42b7a/vmlinux-795c58e4.xz > > > kernel image: https://storage.googleapis.com/syzbot-assets/45ecf25d8ba3/bzImage-795c58e4.xz > > > > > > IMPORTANT: if you fix the issue, please add the following tag to the commit: > > > Reported-by: syzbot+701037856c25b143f1ad@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > > > EXT4-fs (loop3): unmounting filesystem 00000000-0000-0000-0000-000000000000. > > > ================================================================== > > > BUG: KCSAN: data-race in __fsnotify_parent / __fsnotify_recalc_mask > > > > > > write to 0xffff8881001c9d44 of 4 bytes by task 6671 on cpu 1: > > > __fsnotify_recalc_mask+0x216/0x320 fs/notify/mark.c:248 > > > fsnotify_recalc_mask fs/notify/mark.c:265 [inline] > > > fsnotify_add_mark_locked+0x703/0x870 fs/notify/mark.c:781 > > > fsnotify_add_inode_mark_locked include/linux/fsnotify_backend.h:812 [inline] > > > inotify_new_watch fs/notify/inotify/inotify_user.c:620 [inline] > > > inotify_update_watch fs/notify/inotify/inotify_user.c:647 [inline] > > > __do_sys_inotify_add_watch fs/notify/inotify/inotify_user.c:786 [inline] > > > __se_sys_inotify_add_watch+0x66f/0x810 fs/notify/inotify/inotify_user.c:729 > > > __x64_sys_inotify_add_watch+0x43/0x50 fs/notify/inotify/inotify_user.c:729 > > > x64_sys_call+0x2af1/0x2d70 arch/x86/include/generated/asm/syscalls_64.h:255 > > > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > > > do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83 > > > entry_SYSCALL_64_after_hwframe+0x77/0x7f > > > > > > read to 0xffff8881001c9d44 of 4 bytes by task 10004 on cpu 0: > > > fsnotify_object_watched fs/notify/fsnotify.c:187 [inline] > > > __fsnotify_parent+0xd4/0x370 fs/notify/fsnotify.c:217 > > > fsnotify_parent include/linux/fsnotify.h:96 [inline] > > > fsnotify_file include/linux/fsnotify.h:131 [inline] > > > fsnotify_open include/linux/fsnotify.h:401 [inline] > > > vfs_open+0x1be/0x1f0 fs/open.c:1093 > > > do_open fs/namei.c:3654 [inline] > > > path_openat+0x1ad9/0x1fa0 fs/namei.c:3813 > > > do_filp_open+0xf7/0x200 fs/namei.c:3840 > > > do_sys_openat2+0xab/0x120 fs/open.c:1413 > > > do_sys_open fs/open.c:1428 [inline] > > > __do_sys_openat fs/open.c:1444 [inline] > > > __se_sys_openat fs/open.c:1439 [inline] > > > __x64_sys_openat+0xf3/0x120 fs/open.c:1439 > > > x64_sys_call+0x1057/0x2d70 arch/x86/include/generated/asm/syscalls_64.h:258 > > > do_syscall_x64 arch/x86/entry/common.c:52 [inline] > > > do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83 > > > entry_SYSCALL_64_after_hwframe+0x77/0x7f > > > > > > value changed: 0x00000000 -> 0x00002008 > > > > > > Reported by Kernel Concurrency Sanitizer on: > > > CPU: 0 PID: 10004 Comm: syz-executor Not tainted 6.10.0-rc6-syzkaller-00069-g795c58e4c7fc #0 > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 > > > ================================================================== > > > > > > I think __fsnotify_recalc_mask() can be compiled along the lines of: > > > > *fsnotify_conn_mask_p(conn) = 0; > > hlist_for_each_entry(mark, &conn->list, obj_list) { > > ... > > *fsnotify_conn_mask_p(conn) |= fsnotify_calc_mask(mark); > > ... > > } > > > > And then fsnotify_object_watched() may falsely return that it's not > > watched (if it observes 0, or any other incomplete value). > > As far as I know, this is by design that fsnotify_object_watched() > is a relaxed test that allows for false negatives right after watch was added. > At least this has always been the case. > > The question is whether a system call (e.g. open) that started strictly > after the inotify_add_watch() syscall returned success can realistically > observe an incomplete mask, because if the two syscalls are racing > this data race is not interesting. > > Jan, > > WDYT? > If this is the case, then is there a way to annotate access to > *_fsnotify_mask to > silence KCSAN warnings? I meant a case when one notification object is watching inode and set inode->i_fsnotify_mask to something. Then another unrelated notification object starts watching the same inode and temporarily resets the mask to 0 during recalculation. As a result the first object can miss a notification. But I am looking at this code for the first time, so I may be missing something.
