[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+81fdaf...@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 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

[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+81fdaf...@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.

[Marco Elver]

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.

[Christian Brauner]

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.

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

[syzbot]

Auto-closing this bug as obsolete.
Crashes did not happen for a while, no reproducer and no activity.