From nobody Thu Mar 28 10:57:46 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) client-ip=216.205.24.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1633691605; cv=none; d=zohomail.com; s=zohoarc; b=ccmLtMZ6B1lXY1sOjQoJAn0dbvFQwQeD1jkpJw2XBouTUNVwdGx0tfMBTtqCBbJmwMDXSasNEnR1/hoVVqAC69P0b+wlrVg/59GOIupCjqkpFtitGBJSDu8DvyWbmK29oZjF0zoCaF0zey1t3I8NGfcWfBckG3DCmqd7bpsDOOw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1633691605; h=Content-Type:Content-Transfer-Encoding:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=rMuS6Vs6x0U+SmSRGC86vTky0h2HumdGkKMfiRBKciI=; b=mGpc0o7NjZKV/UuJohqpGy5umTKtR7lfe7WcZQHWu0SjhhbnPMKgwLyT6MGUG/kvNwxF/I/bo3zqBoeLLsfSeXNJFcCG3kxSjNJW00fyX848xMsbA0CPbTWsPFDRPNhpTRgrL8yhLZpIuPegygSGIdYA+H4Q5SttNgKqjtNj9Q8= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 216.205.24.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by mx.zohomail.com with SMTPS id 1633691605174878.3085229950772; Fri, 8 Oct 2021 04:13:25 -0700 (PDT) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-581-e5bdVZnAOXGyn_sO5WypDw-1; Fri, 08 Oct 2021 07:13:10 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6C22D100B700; Fri, 8 Oct 2021 11:13:05 +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 A77CC60936; Fri, 8 Oct 2021 11:13:03 +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 1C1744E58F; Fri, 8 Oct 2021 11:13:02 +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 198BD0Q6011690 for ; Fri, 8 Oct 2021 07:13:00 -0400 Received: by smtp.corp.redhat.com (Postfix) id 5AAB91346F; Fri, 8 Oct 2021 11:13:00 +0000 (UTC) Received: from maggie.redhat.com (unknown [10.43.2.26]) by smtp.corp.redhat.com (Postfix) with ESMTP id D9A4D60657 for ; Fri, 8 Oct 2021 11:12:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1633691604; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=rMuS6Vs6x0U+SmSRGC86vTky0h2HumdGkKMfiRBKciI=; b=aHX/R1XzPC6pYJTmK9w2XMQIK9NuW9R9YFxaOMwG6EmcfFSVMpydXrckvW2S8UtbSaL6/T l/+4hDMqzg/oVkFw9+pNMQv6YLIr+aZSVN4tUPnq4171F1FfV0vNNCW7AO9xPwEH/WcnaL R+0LwVU417Ws5d9w8eP9rK0MqBFpO90= X-MC-Unique: e5bdVZnAOXGyn_sO5WypDw-1 From: Michal Privoznik To: libvir-list@redhat.com Subject: [PATCH] vireventglib: Remove handles with the highest priority Date: Fri, 8 Oct 2021 13:12:49 +0200 Message-Id: <3243d1845ae8ee04a05b3463b2e082fd7e0eaa1e.1633691528.git.mprivozn@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-loop: libvir-list@redhat.com 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: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=libvir-list-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) X-ZM-MESSAGEID: 1633691606763100001 Content-Type: text/plain; charset="utf-8" When a server decides to close a client, the virNetServerClientCloseLocked() is called. In here various cleanup steps are taken, but the most important part (from this commit's POV at least) is the way that the socket is closed. Firstly, removal of the socket associated with the client from the event loop is signalized and then the socket is unrefed. The socket is not closed just yet though, because the event loop holds a reference to it. This reference will be freed as soon as the event loop wakes up and starts issuing callbacks (in this case virNetSocketEventFree()). So far, this is how things usually work. But if the daemon reaches the number of opened files limit, things start to work differently. If the RLIMIT_NOFILE limit is reached and there's a client that wants to connect then the event loop wakes up, sees POLLIN on the socket and calls virNetServerServiceAccept() which in turn calls virNetSocketAccept(). But because of the limit, accept() fails with EMFILE leaving the POLLIN event unhandled. The dispatch then continues to next FDs with events on them. BUT, it will NOT call the socket removal callback (virNetSocketEventFree()) because it has low priority (G_PRIORITY_DEFAULT_IDLE). Per glib's documentation: * Each event source is assigned a priority. The default priority, * %G_PRIORITY_DEFAULT, is 0. Values less than 0 denote higher priorities. * Values greater than 0 denote lower priorities. Events from high priority * sources are always processed before events from lower priority sources. and per g_idle_add() documentation: * Adds a function to be called whenever there are no higher priority * events pending to the default main loop. The function is given the * default idle priority, %G_PRIORITY_DEFAULT_IDLE. Now, because we did not accept() the client we are constantly seeing POLLIN on the main socket and thus the removal of the client socket won't ever happen. The fix is to set at least the same priority as other sources, but since we want to just close an FD, let's give it the highest priority and call it before handling other events. This issue can be easily reproduced, for instance: # ulimit -S -n 40 (tweak this number if needed) # ./src/libvirtd from another terminal: # for ((i=3D0; i<100; i++)); do virsh list & done; virsh list The last `virsh list` must not get stuck. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=3D2007168 Signed-off-by: Michal Privoznik --- src/util/vireventglib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/util/vireventglib.c b/src/util/vireventglib.c index f3e5a344b0..983787932f 100644 --- a/src/util/vireventglib.c +++ b/src/util/vireventglib.c @@ -287,7 +287,7 @@ virEventGLibHandleRemove(int watch) * 'removed' to prevent reuse */ data->removed =3D TRUE; - g_idle_add(virEventGLibHandleRemoveIdle, data); + g_idle_add_full(G_PRIORITY_HIGH, virEventGLibHandleRemoveIdle, data, N= ULL); =20 ret =3D 0; =20 --=20 2.32.0