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

Thanks for keeping an eye on this!

Michal

Reply via email to