Re: [libvirt] [PATCH v3 6/6] nodedev: Work around the uevent race by hooking up virFileWaitForAccess

On 08/24/2017 07:23 AM, Erik Skultety wrote: > If we find ourselves in the situation that the 'add' uevent has been > fired earlier than the sysfs tree for a device was created, we should > use the best-effort approach and give kernel some predetermined amount > of time, thus waiting for the attributes to be ready rather than > discarding the device from our device list forever. If those don't appear > in the given time frame, we need to move on, since libvirt can't wait > indefinitely. > > Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1463285 > > Signed-off-by: Erik Skultety <eskultet(a)redhat.com&gt; > --- > src/node_device/node_device_udev.c | 16 +++++++++++++++- > 1 file changed, 15 insertions(+), 1 deletion(-) > IIRC - I pointed out to you that this is eerily familiar to something that happens in the vHBA code w/r/t to wwnn/wwpn files. Except that the files exist, but have a -1 in them which is totally bogus. Then some magic thing happens and the real wwnn/wwpn is placed into the file, but libvirt already looked and failed. When I tried to work around this the decision was to let it be and call it a kernel / udev bug. https://www.redhat.com/archives/libvir-list/2016-June/msg02213.html and Daniel's answer https://www.redhat.com/archives/libvir-list/2016-July/msg00912.html Although yes, with the other changes in place one would think having a wait is no big deal. Still are you guaranteed that once the file exists that the data within the file is valid? In the vHBA case it wasn't and that led to issues.

I'd "use this" processing instead of the hack I proposed as well seeing as it doesn't seem kernel/udev fixing issues such as these is on any priority list /-{