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.
--
Thanks,
Jeffle
