On Tue, Jun 20, 2017 at 01:59:59PM -0400, John Ferlan wrote: > > > On 06/20/2017 11:03 AM, Erik Skultety wrote: > > This series resolves https://bugzilla.redhat.com/show_bug.cgi?id=1463285 > > > > Erik Skultety (3): > > util: Report an error when virFileResolveLinkHelper's lstat fails > > util: Introduce virFileWaitForAccess > > nodedev: Work around the uevent race by hooking up > > virFileWaitForAccess > > > > src/libvirt_private.syms | 1 + > > src/node_device/node_device_udev.c | 48 +++++++++++++++++++++++++++++++++++++- > > src/util/virfile.c | 40 ++++++++++++++++++++++++++++++- > > src/util/virfile.h | 2 ++ > > 4 files changed, 89 insertions(+), 2 deletions(-) > > > > -- > > 2.13.1 > > > > -- > > libvir-list mailing list > > libvir-list@xxxxxxxxxx > > https://www.redhat.com/mailman/listinfo/libvir-list > > > > FWIW: This seemed a bit familiar to something for NPIV as well. Although > for NPIV the files exist, it's just that they have bogus data. See: > > https://www.redhat.com/archives/libvir-list/2016-June/msg02213.html So I read the reply as well and though the argument about leaving kernel bugs to kernel to fix is right, this may take and indefinite time to actually get the fix and having an open kernel BZ is about it in terms what we can do about it. So, in order to make things work in the meantime, we have to work around things - discouraging? yes, ugly? absolutely, but unfortunately necessary. > > The referenced bz: > > https://bugzilla.redhat.com/show_bug.cgi?id=1319544 > > The settle code is used in a number of place in libvirt, search on > virWaitForDevices Thanks for the hint, I was looking for exactly something like this, but that function would not work in this case, because it would indeed wait for /dev/vfio/XY to get created, but for nodedev purposes we don't list those devices and mdevs are only matter of sysfs which is out of scope of udev. Erik -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
