From nobody Mon Feb 9 19:22:08 2026 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 1505753654739116.41881205053346; Mon, 18 Sep 2017 09:54:14 -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 8C44C68D3; Mon, 18 Sep 2017 16:54:13 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 668406047B; Mon, 18 Sep 2017 16:54:13 +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 2C8F5410B2; Mon, 18 Sep 2017 16:54:13 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id v8IGZCq9015759 for ; Mon, 18 Sep 2017 12:35:12 -0400 Received: by smtp.corp.redhat.com (Postfix) id 6C4FD18A5F; Mon, 18 Sep 2017 16:35:12 +0000 (UTC) Received: from beluga.usersys.redhat.com (unknown [10.43.2.166]) by smtp.corp.redhat.com (Postfix) with ESMTP id BEE9318943; Mon, 18 Sep 2017 16:35:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8C44C68D3 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: Mon, 18 Sep 2017 18:34:47 +0200 Message-Id: <3d1af4740817c4ca8ca787c42f2ea4f96a99fc44.1505752213.git.eskultet@redhat.com> In-Reply-To: References: In-Reply-To: References: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-loop: libvir-list@redhat.com Cc: Erik Skultety Subject: [libvirt] [PATCH v4 5/7] 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]); Mon, 18 Sep 2017 16:54:14 +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 96760d1e4..70e15ffb8 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -1696,6 +1696,7 @@ udevEventCheckMonitorFD(struct udev_monitor *udev_mon= itor, 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; @@ -1715,6 +1716,7 @@ udevEventHandleThread(void *opaque) virMutexUnlock(&privateData->lock); =20 nodeDeviceLock(); + priv =3D driver->privateData; udev_monitor =3D DRV_STATE_UDEV_MONITOR(driver); =20 if (!udevEventCheckMonitorFD(udev_monitor, privateData->monitor_fd= )) { @@ -1725,6 +1727,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")); @@ -1750,10 +1755,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); =20 if (!udevEventCheckMonitorFD(udev_monitor, fd)) { @@ -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.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list