On Thu, Sep 04, 2025 at 04:20:24AM +0100, Al Viro wrote: > On Thu, Sep 04, 2025 at 10:17:29AM +1000, Dave Chinner wrote: > > > > I'm doing > > > a bisection between v6.12 and v6.10 at the moment, will post when I get > > > something more useful... > > > > check-parallel is relatively new so, unfortunately, I don't have any > > idea when this behaviour might have been introduced. > > > > FWIW, 'udevadm wait' is relatively new behaviour for both udev and > > fstests. It was introduced into fstests for check-parallel to > > replace 'udevadm settle'. i.e. wait for the specific device to > > change to a particular state rather than waiting for the entire udev > > queue to drain. Check-parallel uses hundreds of block devices and > > filesystems at the same time resulting in multiple mount/unmount > > occurring every second. Hence waiting on the udev queue to drain > > can take a -long- time, but maybe waiting on the device node state > > chang itself is racy (i.e. might be a udevadm or DM bug) and PREEMPT > > is opening up that window. > > FWIW, right now it's down to two likely merges, both in 6.12-rc1 window: > sched and vfs_blocksize (the latter - with iomap and xfs branches in > it). There's the third merge in that range, but it's ext4, so I'm > pretty sure that the next one will be git bisect bad, leaving these > two. Bugger... Either I've got false 'good' at several points, or it's something brought in by commit 2004cef11ea0 "Merge tag 'sched-core-2024-09-19' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip" - bisection has converged to something within the first 48 commits of the branch in question. Which is not impossible, but then the underlying race could've been there for years before that, only to be exposed by timing changes ;-/ Anyway, I'll get the bisection to the end, but it looks like the end result won't be particularly useful...
