Re: [PATCH] avoid endless udevadm wait

[David Disseldorp <ddiss@suse.de>]

[digging up an old thread]

Hi Dave,

On Wed, 12 Mar 2025 07:48:51 +1100, Dave Chinner wrote:

> On Tue, Mar 11, 2025 at 04:03:47PM +1100, David Disseldorp wrote:
> > "udevadm wait <dev>" without a --timeout=SECONDS parameter will wait
> > endlessly. Endless wait can be triggered in f2fs/008 by e.g. using a
> > zram device as a SCRATCH_DEV, where "device type is unknown" failure
> > sees the /dev/mapper/$vgname-$lvname node never appear.
> > 
> > Signed-off-by: David Disseldorp <ddiss@suse.de>
> > ---
> > It might make more sense to add a default timeout to _udev_wait(), but
> > that could also call udev{adm }settle.  
> 
> One of the points of moving to _udev_wait was to explicitly wait for
> the specific device to appear or disappear, indicating that the
> previous admin operations have completed. 'udevadm settle' does not
> do that - it waits for the global queue of events to drain and
> dev config failure doesn't generate udev events.
> 
> Hence tests that silently fail dm/lvm device setup will continue to
> run on something they shouldn't have, and nobody will realise that
> the LVM setup did not run correctly.
> 
> OTOH, _udev_wait() will hang in that situation because it's waiting
> for the device node to appear (or disappear) so it can be
> immediately used. We don't need udev to finish draining queues - we
> only need to wait for the device node to appear and the test is good
> to go.
> 
> This behaviour provides obvious failures when device setup/teardown
> fails in some way. This should not happen, and when it does
> _udev_wait hanging forces that failure to be triaged and fixed
> immediately....
> 
> If we add a timeout to _udev_wait(), then we're back to the old
> behaviour where device config failures get ignored and the test runs
> incorrectly. Except now it is worse because we have to wait a
> timeout before the test is then run....

I've revisited this, as I manage to break udevd once a year or so in my
minimal initramfs-based xfstests env. I find a timeout with
golden-output breaking error message much easier to debug than an
endless loop. Please see:

https://lore.kernel.org/fstests/20260319005154.29274-1-ddiss@suse.de/T/#u