v2 here: https://www.redhat.com/archives/libvir-list/2017-July/msg01268.html

Since v2:
- added patch 4/6 that fixes the issue with the handler thread spamming logs
with "udev_monitor_receive_device returned NULL"
  -> the event loop callback now disables polling on the udev monitor's fd
     every time there's a new event, leaving the responsibility for re-enabling
     it back to the handler thread once it had removed the corresponding data
     from the socket.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1463285

Erik Skultety (6):
  nodedev: Introduce udevCheckMonitorFD helper function
  udev: Split udevEventHandleCallback in two functions
  udev: Convert udevEventHandleThread to an actual thread routine
  nodedev: Disable/re-enable polling on the udev fd
  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 | 208 ++++++++++++++++++++++++++++++++-----
 src/util/virfile.c                 |  29 ++++++
 src/util/virfile.h                 |   2 +
 4 files changed, 214 insertions(+), 26 deletions(-)

--
2.13.3

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Thu, Aug 24, 2017 at 01:23:26PM +0200, Erik Skultety wrote:
> v2 here: https://www.redhat.com/archives/libvir-list/2017-July/msg01268.html
>
> Since v2:
> - added patch 4/6 that fixes the issue with the handler thread spamming logs
> with "udev_monitor_receive_device returned NULL"
>   -> the event loop callback now disables polling on the udev monitor's fd
>      every time there's a new event, leaving the responsibility for re-enabling
>      it back to the handler thread once it had removed the corresponding data
>      from the socket.
>
> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1463285

ping

Erik

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On 09/18/2017 01:53 AM, Erik Skultety wrote:
> On Thu, Aug 24, 2017 at 01:23:26PM +0200, Erik Skultety wrote:
>> v2 here: https://www.redhat.com/archives/libvir-list/2017-July/msg01268.html
>>
>> Since v2:
>> - added patch 4/6 that fixes the issue with the handler thread spamming logs
>> with "udev_monitor_receive_device returned NULL"
>>   -> the event loop callback now disables polling on the udev monitor's fd
>>      every time there's a new event, leaving the responsibility for re-enabling
>>      it back to the handler thread once it had removed the corresponding data
>>      from the socket.
>>
>> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1463285
> 
> ping
> 

I think I had assumed there was going to be a v4...  Was I incorrect and
you would prefer to keep this series as is presented here?

John

> Erik
> 
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
> 

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On Mon, Sep 18, 2017 at 08:47:52AM -0400, John Ferlan wrote:
>
>
> On 09/18/2017 01:53 AM, Erik Skultety wrote:
> > On Thu, Aug 24, 2017 at 01:23:26PM +0200, Erik Skultety wrote:
> >> v2 here: https://www.redhat.com/archives/libvir-list/2017-July/msg01268.html
> >>
> >> Since v2:
> >> - added patch 4/6 that fixes the issue with the handler thread spamming logs
> >> with "udev_monitor_receive_device returned NULL"
> >>   -> the event loop callback now disables polling on the udev monitor's fd
> >>      every time there's a new event, leaving the responsibility for re-enabling
> >>      it back to the handler thread once it had removed the corresponding data
> >>      from the socket.
> >>
> >> Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1463285
> >
> > ping
> >
>
> I think I had assumed there was going to be a v4...  Was I incorrect and
> you would prefer to keep this series as is presented here?

Oh, I managed to somehow forget about the comments in patches 1-2 as I fixed
them locally and then solely focused on our technical discussion in patches
3-6. No problem, I'll resend a v4 adjusting the first two patches, since there
weren't any semantic-related points, rather than points regarding the whole
idea in general.

Erik

>
> John
>
> > Erik
> >
> > --
> > libvir-list mailing list
> > libvir-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/libvir-list
> >

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list