From nobody Fri May 16 01:08:48 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1503573835074522.2690737072953; Thu, 24 Aug 2017 04:23:55 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 274B85F7A9; Thu, 24 Aug 2017 11:23:53 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 02E9E77D71; Thu, 24 Aug 2017 11:23:53 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id BE2E31806107; Thu, 24 Aug 2017 11:23:52 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id v7OBNgnu010857 for ; Thu, 24 Aug 2017 07:23:42 -0400 Received: by smtp.corp.redhat.com (Postfix) id E709D7B55E; Thu, 24 Aug 2017 11:23:42 +0000 (UTC) Received: from beluga.usersys.redhat.com (unknown [10.43.2.36]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2A6057B52C; Thu, 24 Aug 2017 11:23:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 274B85F7A9 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=libvir-list-bounces@redhat.com From: Erik Skultety To: libvir-list@redhat.com Date: Thu, 24 Aug 2017 13:23:30 +0200 Message-Id: In-Reply-To: References: In-Reply-To: References: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-loop: libvir-list@redhat.com Cc: Erik Skultety Subject: [libvirt] [PATCH v3 4/6] nodedev: Disable/re-enable polling on the udev fd X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 24 Aug 2017 11:23:53 +0000 (UTC) X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" The event loop may get scheduled earlier than the udev event handler thread which means that it would keep invoking the handler callback with "new" events, while in fact it's most likely still the same event which the handler thread hasn't managed to remove from the socket queue yet. This is due to unwanted increments of the number of events queuing on the socket and causes the handler thread to spam the logs with an error about libudev returning NULL (errno =3D=3D EAGAIN). Signed-off-by: Erik Skultety --- src/node_device/node_device_udev.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_devi= ce_udev.c index 444e5be4d..e3a647e3d 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -1697,6 +1697,7 @@ udevCheckMonitorFD(struct udev_monitor *udev_monitor,= int fd) static void udevEventHandleThread(void *opaque) { + udevPrivate *priv =3D NULL; udevEventThreadDataPtr privateData =3D opaque; struct udev_device *device =3D NULL; struct udev_monitor *udev_monitor =3D NULL; @@ -1716,6 +1717,7 @@ udevEventHandleThread(void *opaque) virMutexUnlock(&privateData->lock); =20 nodeDeviceLock(); + priv =3D driver->privateData; udev_monitor =3D DRV_STATE_UDEV_MONITOR(driver); =20 if (!udevCheckMonitorFD(udev_monitor, privateData->monitor_fd)) { @@ -1726,6 +1728,9 @@ udevEventHandleThread(void *opaque) device =3D udev_monitor_receive_device(udev_monitor); nodeDeviceUnlock(); =20 + /* Re-enable polling for new events on the @udev_monitor */ + virEventUpdateHandle(priv->watch, VIR_EVENT_HANDLE_READABLE); + if (!device) { virReportError(VIR_ERR_INTERNAL_ERROR, "%s", _("udev_monitor_receive_device returned NULL")); @@ -1751,10 +1756,12 @@ udevEventHandleCallback(int watch ATTRIBUTE_UNUSED, int events ATTRIBUTE_UNUSED, void *opaque) { + udevPrivate *priv =3D NULL; struct udev_monitor *udev_monitor =3D NULL; udevEventThreadDataPtr threadData =3D opaque; =20 nodeDeviceLock(); + priv =3D driver->privateData; udev_monitor =3D DRV_STATE_UDEV_MONITOR(driver); if (!udevCheckMonitorFD(udev_monitor, fd)) { virMutexLock(&threadData->lock); @@ -1771,6 +1778,16 @@ udevEventHandleCallback(int watch ATTRIBUTE_UNUSED, threadData->nevents++; virCondSignal(&threadData->threadCond); virMutexUnlock(&threadData->lock); + + /* Due to scheduling, the eventloop might poll the udev monitor before= the + * handler thread actually removes the data from the socket, thus caus= ing it + * to spam errors about data not being ready yet, because + * udevEventHandleCallback would be invoked multiple times incrementin= g the + * counter of events queuing for a single event. + * Therefore we need to disable polling on the fd until the thread act= ually + * removes the data from the socket. + */ + virEventUpdateHandle(priv->watch, 0); } =20 =20 --=20 2.13.3 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list