On 7/12/21 5:05 PM, Matteo Croce wrote: > From: Matteo Croce <mcroce@xxxxxxxxxxxxx> > > Associating uevents with block devices in userspace is difficult and racy: > the uevent netlink socket is lossy, and on slow and overloaded systems has > a very high latency. Block devices do not have exclusive owners in > userspace, any process can set one up (e.g. loop devices). Moreover, device > names can be reused (e.g. loop0 can be reused again and again). A userspace > process setting up a block device and watching for its events cannot thus > reliably tell whether an event relates to the device it just set up or > another earlier instance with the same name. > > Being able to set a UUID on a loop device would solve the race conditions. > But it does not allow to derive orderings from uevents: if you see a uevent > with a UUID that does not match the device you are waiting for, you cannot > tell whether it's because the right uevent has not arrived yet, or it was > already sent and you missed it. So you cannot tell whether you should wait > for it or not. > > Being able to set devices up in a namespace would solve the race conditions > too, but it can work only if being namespaced is feasible in the first > place. Many userspace processes need to set devices up for the root > namespace, so this solution cannot always work. > > Changing the loop devices naming implementation to always use > monotonically increasing device numbers, instead of reusing the lowest > free number, would also solve the problem, but it would be very disruptive > to userspace and likely break many existing use cases. It would also be > quite awkward to use on long-running machines, as the loop device name > would quickly grow to many-digits length. > > Furthermore, this problem does not affect only loop devices - partition > probing is asynchronous and very slow on busy systems. It is very easy to > enter races when using LO_FLAGS_PARTSCAN and watching for the partitions to > show up, as it can take a long time for the uevents to be delivered after > setting them up. > > Associating a unique, monotonically increasing sequential number to the > lifetime of each block device, which can be retrieved with an ioctl > immediately upon setting it up, allows to solve the race conditions with > uevents, and also allows userspace processes to know whether they should > wait for the uevent they need or if it was dropped and thus they should > move on. > > This does not benefit only loop devices and block devices with multiple > partitions, but for example also removable media such as USB sticks or > cdroms/dvdroms/etc. > > The first patch is the core one, the 2..4 expose the information in > different ways, and the last one makes the loop device generate a media > changed event upon attach, detach or reconfigure, so the sequence number > is increased. > > If merged, this feature will immediately used by the userspace: > https://github.com/systemd/systemd/issues/17469#issuecomment-762919781 Applied for 5.15, with #2 done manually since it didn't apply cleanly. -- Jens Axboe
