Message-ID: <CACT4Y+bHG2KWut-wm8i==dm9j954gAsYFU0YkYitsdchg9i5Xg@mail.gmail.com>
Date: Fri, 5 Jul 2024 10:36:58 +0200
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Amir Goldstein <amir73il@...il.com>
Cc: syzbot <syzbot+701037856c25b143f1ad@...kaller.appspotmail.com>, jack@...e.cz, 
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [fs?] KCSAN: data-race in __fsnotify_parent /
 __fsnotify_recalc_mask (5)

On Fri, 5 Jul 2024 at 08:02, Amir Goldstein <amir73il@...il.com> wrote:
>
> On Thu, Jul 4, 2024 at 5:28 PM Dmitry Vyukov <dvyukov@...gle.com> wrote:
> >
> > On Thu, 4 Jul 2024 at 16:22, syzbot
> > <syzbot+701037856c25b143f1ad@...kaller.appspotmail.com> 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@...kaller.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
> > > ==================================================================
> >
> >
> > 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.

Powered by blists - more mailing lists