From nobody Wed Apr 24 18:15:09 2024 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; dmarc=pass(p=none dis=none) header.from=redhat.com Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1539951720047992.2388716306399; Fri, 19 Oct 2018 05:22:00 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 62FF73003D5C; Fri, 19 Oct 2018 12:21:58 +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 1E9C56530B; Fri, 19 Oct 2018 12:21:58 +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 A18771801255; Fri, 19 Oct 2018 12:21:57 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id w9JC4nnj009494 for ; Fri, 19 Oct 2018 08:04:49 -0400 Received: by smtp.corp.redhat.com (Postfix) id 328BE600C0; Fri, 19 Oct 2018 12:04:49 +0000 (UTC) Received: from unknown54ee7586bd10.attlocal.net.com (ovpn-116-156.phx2.redhat.com [10.3.116.156]) by smtp.corp.redhat.com (Postfix) with ESMTP id E18B96C400 for ; Fri, 19 Oct 2018 12:04:46 +0000 (UTC) From: John Ferlan To: libvir-list@redhat.com Date: Fri, 19 Oct 2018 08:04:43 -0400 Message-Id: <20181019120443.2733-1-jferlan@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH] nodedev: Document the udevEventHandleThread 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.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Fri, 19 Oct 2018 12:21:59 +0000 (UTC) X-ZohoMail: RDMRC_0 RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" Add details of the algorithm and why it was used to help future readers understand the issues encountered. Based largely off a description provided by Erik Skultety . Signed-off-by: John Ferlan --- see: https://www.redhat.com/archives/libvir-list/2018-October/msg00915.html src/node_device/node_device_udev.c | 49 ++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/src/node_device/node_device_udev.c b/src/node_device/node_devi= ce_udev.c index 22897591de..8ca81e65ad 100644 --- a/src/node_device/node_device_udev.c +++ b/src/node_device/node_device_udev.c @@ -1591,6 +1591,53 @@ udevEventMonitorSanityCheck(udevEventDataPtr priv, } =20 =20 +/** + * udevEventHandleThread + * @opaque: unused + * + * Thread to handle the udevEventHandleCallback processing when udev + * tells us there's a device change for us (add, modify, delete, etc). + * + * Management of the processing udev device notification is a delicate + * balance between the udev process, the scheduler, and when exactly the + * data from/for the socket is received. The udev processing code notifies + * the udevEventHandleCallback that it has data; however, the actual recv() + * done in the udev code to fill in the @device structure can be delayed + * due to how threads are scheduled. + * + * As it turns out, the event loop could be scheduled (and it in fact + * was) earlier than the handler thread. What that essentially means is + * that by the time the thread actually handled the event and read the + * data from the monitor, the event loop fired the very same event, simply + * because the data hadn't been retrieved from the socket at that point ye= t. + * + * Thus this algorithm is that once udevEventHandleCallback is notified + * there is data, this loop will process as much data as possible until + * udev_monitor_receive_device fails to get the @device. This may be + * because we've processed everything or because the scheduling thread + * hasn't been able to populate data in the socket. Once we're done + * processing everything we can, wait on the next event/notification. + * Although this may incur a slight delay if the socket data wasn't + * populated, the event/notifications are fairly consistent so there's + * no need to use virCondWaitUntil. + * + * NB: Usage of event based socket algorithm causes some issues with + * older platforms such as CentOS 6 in which the data socket is opened + * without the NONBLOCK bit set. Still even if the reset of priv->dataReady + * were moved to just after the udev_monitor_receive_device in order to + * avoid the NONBLOCK issue, the scheduler would still come into play + * especially for environments when multiple devices are added into the + * system. Even those environments would still be blocked on the udev + * socket recv() call. The algorithm for handling that scenario would + * be more complex and involve pulling the monitor object out of the + * private data lockable object and would need to be guarded by a + * separate lock. Devising algorithms to work around issues with older + * OS's at the expense of more modern OS algorithms in newer event + * processing code may result in unexpected issues, so the choice is + * to encourage use of newer OS's with newer udev event processing code. + * Newer devices, such as mdevs make heavy usage of event processing + * and it's expected future devices would follow that model. + */ static void udevEventHandleThread(void *opaque ATTRIBUTE_UNUSED) { @@ -1637,6 +1684,8 @@ udevEventHandleThread(void *opaque ATTRIBUTE_UNUSED) return; } =20 + /* See the above description why this needs to be here + * and not after the udev_monitor_receive_device. */ virObjectLock(priv); priv->dataReady =3D false; virObjectUnlock(priv); --=20 2.17.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list