[syzbot] [fs?] KCSAN: data-race in __fsnotify_parent / __fsnotify_recalc_mask (5)

[syzbot]

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+701037...@syzkaller.appspotmail.com

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


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[Dmitry Vyukov]

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

[Amir Goldstein]

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?

Thanks,
Amir.

[Dmitry Vyukov]

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.