Comment 5 for bug 1892895

I opened https://github.com/snapcore/snapd/pull/10975 specifically for microstack which should resolve the bug for microstack, but this bug is indeed a more general problem wherein a snap application knows about a new device node from the kernel but that device node has not been processed by udev yet.

I wonder if applications like microstack which get information directly from the kernel about a given device node before udev has a chance to process the new device node could instead do one of two things to avoid this race entirely:

1. Just always loop trying to access this block device (with reasonable timeouts) if the error is specifically EPERM, with the assumption that it will eventually be asynchronously allowed by udev when udev has a chance to trigger the snap-device-helper which will update the snap's device cgroup to allow the new specific device that the snap knows about before udev has processed.

2. After learning about the new device node from the kernel, before trying to access it at all, synchronously trigger udev to process the new rule and wait for udev to be finished before accessing the device node. This should entirely eliminate the race because the race here is really between the application and udev, not really between the application and the snap-device-helper.

Long term, we may look at other mechanisms to know about these sorts of changes sooner than udev (i.e. a more immediate way that maybe happens before the kernel releases to userspace the information about the device node if that is possible), but I happen to be of the opinion right now that there will always fundamentally be this sort of race between something privileged in userspace asking/telling the kernel to create a device and udev responding to that device creation since udev is in userspace.