On 2/7/21 7:56 PM, Greg KH wrote:
On Sun, Feb 07, 2021 at 07:46:54PM +0800, Jeffle Xu wrote:
commit fef912bf860e8e7e48a2bfb978a356bba743a8b7 upstream. commit e982c4d0a29b1d61fbe7716a8dcf8984936d6730 upstream.
Similar to commit 9e07f4e24379 ("zram: close udev startup race condition as default groups"), this is a merge of [1, 2], since [1] may be too large size to be merged into -stable tree.
Why is it too big?
This issue has been introduced since v2.6.36 by [3].
[1] fef912bf860e, block: genhd: add 'groups' argument to device_add_disk [2] e982c4d0a29b, virtio-blk: modernize sysfs attribute creation [3] a5eb9e4ff18a, virtio_blk: Add 'serial' attribute to virtio-blk devices (v2)
What userspace tools are now hitting this issue? If it's a real problem, let's take the real commits, right?
Same for the other patches in this series.
udevd hits this issue. systemd-udevd is responsible for creating symlinks, such as '/dev/disk/by-id/XXXX' when receiving KOBJ_ADD uevent from kernel space. For virtio-blk devices, udevd will read '/sys/devices/pciXXXX/block/serial' to acquire the corresponding serial id of the virtio-blk device.
Without this fixing patch, '/sys/devices/pciXXXX/block/serial' is created after the KOBJ_ADD uevent. Thus when udevd received KOBJ_ADD uevent, it may find that '/sys/devices/pciXXXX/block/serial' doesn't exist at that time, and finally failed to create '/dev/disk/by-id/XXXX' symlink.
I found several similar posts on internet, complaining '/dev/disk/by-id/XXXX' is not created for virtio-blk devices. This issue indeed is caused by some sort of race condition. I also found that systemd-239 doesn't have this issue, while systemd-219 has. But we didn't find the exact fixing commit for this issue for systemd-239 though.