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@redhat.com
> > 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@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list