Comment # 1 on bug 1169932 from Michal Koutn�

The trigger are the two kernel patches that fixed "locking":

> d3ef5536274f ("block: fix busy device checking in blk_drop_partitions")
> cb6b771b05c3 ("block: fix busy device checking in blk_drop_partitions again")

losetup isn't "atomic" operation:
> strace -e ioctl losetup --find --show --partscan ~/image.0.raw 
> (1) ioctl(3, LOOP_CTL_GET_FREE)             = 1
>     ioctl(4, LOOP_SET_FD, 3)                = 0
> (2) ioctl(4, LOOP_SET_STATUS64, {lo_offset=0, lo_number=0, lo_flags=LO_FLAGS_PARTSCAN, lo_file_name="/home/mkoutny/image.0.raw", ...}) = 0

Somewhere between (1) and (2) uevent is triggered and udevd opens the device
and (2) fails. Note that ioctl apparently succeeds (EBUSY is swallowed in
kernel).

TBH, I don't know what a good fix would be. Perhaps udevd being more careful
when processing loop uevents? (I'm reassigning to systemd-maintainers, CCing
util-linux maintainer).

Also keyword: mkosi