this commit addresses the same issue that as commit 1af45804 does.
the following message is copying from that commit:
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.
Signed-off-by: Guoyi Tu <t...@chinatelecom.cn>
---
src/node_device/node_device_udev.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/src/node_device/node_device_udev.c
b/src/node_device/node_device_udev.c
index 1d8486f623..4a1786c21c 100644
--- a/src/node_device/node_device_udev.c
+++ b/src/node_device/node_device_udev.c
@@ -427,10 +427,19 @@ udevProcessPCI(virNodeDeviceDriverState *driver_state,
virPCIEDeviceInfo *pci_express = NULL;
virPCIDevice *pciDev = NULL;
virPCIDeviceAddress devAddr = { 0 };
+ g_autofree char *linkpath = NULL;
int ret = -1;
char *p;
bool privileged = false;
+ linkpath = g_strdup_printf("%s/config",
udev_device_get_syspath(device));
+ if (virFileWaitForExists(linkpath, 10, 100) < 0) {
+ virReportSystemError(errno,
+ _("failed to wait for file '%1$s' to appear"),
+ linkpath);
+ goto cleanup;
+ }
+
VIR_WITH_MUTEX_LOCK_GUARD(&driver_state->lock) {
privileged = driver_state->privileged;
}
--
2.27.0
--
Guoyi
