On Wed, Apr 08, 2026 at 04:41:13PM +0200, Michal Prívozník wrote:
> On 4/8/26 15:02, Richard W.M. Jones wrote:
> > I just happened upon this while reviewing another patch ...
> > 
> > On Wed, Apr 08, 2026 at 02:16:09PM +0200, Michal Privoznik via Devel wrote:
> >> Therefore, to avoid this problem, wait for udev to settle by
> >> calling virWaitForDevices() (which under the hood spawns "udevadm
> >> settle". This may be a bit too heavy hammer though because the
> >> function is called basically once per (almost) each <interface/>.
> >> If we find that to be a performance drawback then we need to
> >> redesign how tun/tap/... devices are created (well, opened).
> > 
> > I should note that 'udevadm settle' is broken and upstream refuses to
> > fix it, because of course they claim to know better than everyone else:
> > 
> > https://github.com/systemd/systemd/issues/40499
> > 
> > I don't know if this also affects network devices.  I guess it depends
> > if the kernel can emit events in the same way as for block devices.
> > 
> > For block devices our approach has been to continue to use 'udevadm
> > settle' since there is no sane alternative.
> 
> That's very unfortunate, but I don't think it affects network devices,
> given that you bisected udev into a commit that changes how partition
> table is read. I mean, there can be similar bug that affects network
> devices, but I haven't encountered it in my testing (on rawhide).

For sure the change I bisected to was just in the code that rereads
the partition table.  But that commit widened a pre-existing race
condition (and the "fix" narrows it again, but does not close it).
The actual problem is that the kernel can emit udev events _before_
'udevadm settle' runs, and udev doesn't take those into account, so
udevadm settle isn't a proper barrier operation as it claims to be.

Whether this affects network devices or not is going to depend on some
deep kernel details that I'm not familiar with.

Rich.

> Thanks for keeping an eye on this!
> 
> Michal

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

Reply via email to