[syzbot] [fs?] KCSAN: data-race in choose_mountpoint_rcu / umount_tree

[syzbot] [fs?] KCSAN: data-race in choose_mountpoint_rcu / umount_tree

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    a33b5a08cbbd Merge tag 'sched_ext-for-6.15-rc3-fixes' of g..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1058f26f980000
kernel config:  https://syzkaller.appspot.com/x/.config?x=85dd0f8b81b9d41f
dashboard link: https://syzkaller.appspot.com/bug?extid=81fdaf0f522d5c5e41fb
compiler:       Debian clang version 15.0.6, Debian LLD 15.0.6

Unfortunately, I don't have any reproducer for this issue yet.

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/718e6f7bde0a/disk-a33b5a08.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/20f5e402fb15/vmlinux-a33b5a08.xz
kernel image: https://storage.googleapis.com/syzbot-assets/2dd06e277fc7/bzImage-a33b5a08.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+81fdaf0f522d5c5e41fb@syzkaller.appspotmail.com

==================================================================
BUG: KCSAN: data-race in choose_mountpoint_rcu / umount_tree

write to 0xffff888108512d98 of 8 bytes by task 21705 on cpu 1:
 unhash_mnt fs/namespace.c:1050 [inline]
 umount_mnt fs/namespace.c:1064 [inline]
 umount_tree+0x6f0/0xb10 fs/namespace.c:1922
 do_umount fs/namespace.c:-1 [inline]
 path_umount+0x9c1/0xa40 fs/namespace.c:2144
 ksys_umount fs/namespace.c:2167 [inline]
 __do_sys_umount fs/namespace.c:2172 [inline]
 __se_sys_umount fs/namespace.c:2170 [inline]
 __x64_sys_umount+0xb7/0xe0 fs/namespace.c:2170
 x64_sys_call+0x2883/0x2e10 arch/x86/include/generated/asm/syscalls_64.h:167
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xc9/0x1a0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

read to 0xffff888108512d98 of 8 bytes by task 21704 on cpu 0:
 choose_mountpoint_rcu+0x3d/0x130 fs/namei.c:1386
 follow_dotdot_rcu fs/namei.c:2020 [inline]
 handle_dots+0x559/0x790 fs/namei.c:2095
 walk_component fs/namei.c:2132 [inline]
 link_path_walk+0x5f6/0x840 fs/namei.c:2503
 path_lookupat+0x6c/0x2a0 fs/namei.c:2659
 filename_lookup+0x14b/0x340 fs/namei.c:2689
 filename_setxattr+0x59/0x2b0 fs/xattr.c:660
 path_setxattrat+0x28a/0x320 fs/xattr.c:713
 __do_sys_setxattr fs/xattr.c:747 [inline]
 __se_sys_setxattr fs/xattr.c:743 [inline]
 __x64_sys_setxattr+0x6e/0x90 fs/xattr.c:743
 x64_sys_call+0x28e7/0x2e10 arch/x86/include/generated/asm/syscalls_64.h:189
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0xc9/0x1a0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

value changed: 0xffff888116147cc0 -> 0xffff8881065c23c0

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 UID: 0 PID: 21704 Comm: syz.6.5865 Not tainted 6.15.0-rc3-syzkaller-00008-ga33b5a08cbbd #0 PREEMPT(voluntary) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025
==================================================================


---
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 syzkaller@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

Re: [syzbot] [fs?] KCSAN: data-race in choose_mountpoint_rcu / umount_tree

[Christian Brauner]

On Tue, Apr 22, 2025 at 05:11:27AM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following issue on:
> 
> HEAD commit:    a33b5a08cbbd Merge tag 'sched_ext-for-6.15-rc3-fixes' of g..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1058f26f980000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=85dd0f8b81b9d41f
> dashboard link: https://syzkaller.appspot.com/bug?extid=81fdaf0f522d5c5e41fb
> compiler:       Debian clang version 15.0.6, Debian LLD 15.0.6
> 
> Unfortunately, I don't have any reproducer for this issue yet.
> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/718e6f7bde0a/disk-a33b5a08.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/20f5e402fb15/vmlinux-a33b5a08.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/2dd06e277fc7/bzImage-a33b5a08.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+81fdaf0f522d5c5e41fb@syzkaller.appspotmail.com
> 
> ==================================================================
> BUG: KCSAN: data-race in choose_mountpoint_rcu / umount_tree

Benign, as this would be detected by the changed sequence count of
@mount_lock. I hope we won't end up with endless reports about:w
anything that we protect with a seqlock. That'll be very annoying.

Re: [syzbot] [fs?] KCSAN: data-race in choose_mountpoint_rcu / umount_tree

[Marco Elver]

On Tue, 22 Apr 2025 at 15:43, 'Christian Brauner' via syzkaller-bugs
<syzkaller-bugs@googlegroups.com> wrote:
>
> On Tue, Apr 22, 2025 at 05:11:27AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:    a33b5a08cbbd Merge tag 'sched_ext-for-6.15-rc3-fixes' of g..
> > git tree:       upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1058f26f980000
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=85dd0f8b81b9d41f
> > dashboard link: https://syzkaller.appspot.com/bug?extid=81fdaf0f522d5c5e41fb
> > compiler:       Debian clang version 15.0.6, Debian LLD 15.0.6
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/718e6f7bde0a/disk-a33b5a08.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/20f5e402fb15/vmlinux-a33b5a08.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/2dd06e277fc7/bzImage-a33b5a08.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+81fdaf0f522d5c5e41fb@syzkaller.appspotmail.com
> >
> > ==================================================================
> > BUG: KCSAN: data-race in choose_mountpoint_rcu / umount_tree
>
> Benign, as this would be detected by the changed sequence count of
> @mount_lock. I hope we won't end up with endless reports about:w
> anything that we protect with a seqlock. That'll be very annoying.

Seqlocks are generally supported, but have caused headaches in the
past, esp. if the reader-side seqlock critical section does not follow
the typical do-seqbegin-while-retry pattern, or the critical section
is too large. If I read this right, the

  struct dentry *mountpoint = m->mnt_mountpoint;

is before the seqlock-reader beginning with "*seqp =
read_seqcount_begin(&mountpoint->d_seq);" ?

In fact, a lot of the special seqlock rules for KCSAN were conceived
due to irregular seqlock patterns in fs/ - I wouldn't be surprised
there still is the odd false positive here or there. There have also
been recent improvements to KCSAN's seqlock handling, but 6.15-rc*
should have those fixes already.

Re: [syzbot] [fs?] KCSAN: data-race in choose_mountpoint_rcu / umount_tree

[Christian Brauner]

On Tue, Apr 22, 2025 at 04:42:52PM +0200, Marco Elver wrote:
> On Tue, 22 Apr 2025 at 15:43, 'Christian Brauner' via syzkaller-bugs
> <syzkaller-bugs@googlegroups.com> wrote:
> >
> > On Tue, Apr 22, 2025 at 05:11:27AM -0700, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:    a33b5a08cbbd Merge tag 'sched_ext-for-6.15-rc3-fixes' of g..
> > > git tree:       upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=1058f26f980000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=85dd0f8b81b9d41f
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=81fdaf0f522d5c5e41fb
> > > compiler:       Debian clang version 15.0.6, Debian LLD 15.0.6
> > >
> > > Unfortunately, I don't have any reproducer for this issue yet.
> > >
> > > Downloadable assets:
> > > disk image: https://storage.googleapis.com/syzbot-assets/718e6f7bde0a/disk-a33b5a08.raw.xz
> > > vmlinux: https://storage.googleapis.com/syzbot-assets/20f5e402fb15/vmlinux-a33b5a08.xz
> > > kernel image: https://storage.googleapis.com/syzbot-assets/2dd06e277fc7/bzImage-a33b5a08.xz
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+81fdaf0f522d5c5e41fb@syzkaller.appspotmail.com
> > >
> > > ==================================================================
> > > BUG: KCSAN: data-race in choose_mountpoint_rcu / umount_tree
> >
> > Benign, as this would be detected by the changed sequence count of
> > @mount_lock. I hope we won't end up with endless reports about:w
> > anything that we protect with a seqlock. That'll be very annoying.
> 
> Seqlocks are generally supported, but have caused headaches in the
> past, esp. if the reader-side seqlock critical section does not follow
> the typical do-seqbegin-while-retry pattern, or the critical section
> is too large. If I read this right, the
> 
>   struct dentry *mountpoint = m->mnt_mountpoint;
> 
> is before the seqlock-reader beginning with "*seqp =
> read_seqcount_begin(&mountpoint->d_seq);" ?

choose_mountpoint_rcu() is always called within a context where the
seqcount of the mount_lock is taken before it is called. IOW, there's
the secount stored in a dentry like mountpoint->d_seq and then there's
the seqcount of the mount_lock itself. For one callsite in
choose_mountpoint() it's obvious:

                unsigned seq, mseq = read_seqbegin(&mount_lock);

                found = choose_mountpoint_rcu(m, root, path, &seq);
		if (unlikely(!found)) {
                        if (!read_seqretry(&mount_lock, mseq))
                                break;

but for follow_dotdot_rcu()

                if (!choose_mountpoint_rcu(real_mount(nd->path.mnt),
                                           &nd->root, &path, &seq))
                if (read_seqretry(&mount_lock, nd->m_seq))
                        return ERR_PTR(-ECHILD);

nd->m_seq is setup in path_init() or in __legitimize_path() or
__legitimize_mnt(). IOW, it can be a rather complex callchain.

Re: [syzbot] [fs?] KCSAN: data-race in choose_mountpoint_rcu / umount_tree

[Al Viro]

On Tue, Apr 22, 2025 at 04:42:52PM +0200, Marco Elver wrote:

> Seqlocks are generally supported, but have caused headaches in the
> past, esp. if the reader-side seqlock critical section does not follow
> the typical do-seqbegin-while-retry pattern, or the critical section
> is too large. If I read this right, the
> 
>   struct dentry *mountpoint = m->mnt_mountpoint;
> 
> is before the seqlock-reader beginning with "*seqp =
> read_seqcount_begin(&mountpoint->d_seq);" ?

Different seqlock - mount_lock protects mount tree and it's been sampled
all way back in the beginning of RCU pathwalk...