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@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxx > > > > > > ================================================================== > > > 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.
