From nobody Sun Feb 8 14:31:35 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.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 170.10.133.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=1693322006; cv=none; d=zohomail.com; s=zohoarc; b=alyP1cHtcauHPGMKYc0QnZtFDnQuorDsqJDWuxwWtu89yTBcGxbKKSQNJ1pKMJlNM3qSm66jBWWE+pRpaH2GnzPc/1SQJ+wWAxTJk/7Lit/nJrRjO7Pmj4YVFbdyjxX/uTY5JM+spQHsIjKEkyv+bLYsDt6v2TrOp/4yvO6JiFc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1693322006; h=Content-Type:Content-Transfer-Encoding:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=CeOOBTXCU6HJ4WmQKeD8LqH4RbLouqtlOC8NZcPgp/U=; b=fH3HdCwuPJbhhMEie4q+La2QUZ4yHdpODrVq312Wcw7SrjSC0fUtUYxz7wCpiK9A32PCcdv3dlzuqRSmf6vBrpATzGd1iaLJU1ANbChQxMe7f1N6Dt5Sk6AcLt5goQyIUFxFXnzgxipmm+CAb898x38yXuzGWkeeeXLJl9a1wjs= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.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 [170.10.133.124]) by mx.zohomail.com with SMTPS id 1693322006464803.2019115855717; Tue, 29 Aug 2023 08:13:26 -0700 (PDT) Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-70-g8NK0al-OlmogPfrN2J28A-1; Tue, 29 Aug 2023 11:13:22 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 374AE87D285; Tue, 29 Aug 2023 15:13:20 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 24F002166B26; Tue, 29 Aug 2023 15:13:20 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 62E911946A43; Tue, 29 Aug 2023 15:13:14 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 5C27119452CB for ; Tue, 29 Aug 2023 15:13:13 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 4BA5640C2070; Tue, 29 Aug 2023 15:13:13 +0000 (UTC) Received: from localhost.localdomain (unknown [10.43.2.56]) by smtp.corp.redhat.com (Postfix) with ESMTP id E720C40C2063 for ; Tue, 29 Aug 2023 15:13:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1693322005; 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: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=CeOOBTXCU6HJ4WmQKeD8LqH4RbLouqtlOC8NZcPgp/U=; b=Tzatadb6reFNoc+R17fsf4y1Io9PwuMy+HiHRrH5DnUibyzgAQNE9JgLxH+hiWQqeQQ6a/ Bu1oEaKLUYeWjDa7jldWSubFa5mKhHATZQDrwUk/AifIzRPB2bvbwjkoSeOyej2YEkDhez gFbCwGQkbMPobghRMs2FGSHrmDeaWSM= X-MC-Unique: g8NK0al-OlmogPfrN2J28A-1 X-Original-To: libvir-list@listman.corp.redhat.com From: Michal Privoznik To: libvir-list@redhat.com Subject: [PATCH 3/4] vircommand: Make sysconf(_SC_OPEN_MAX) failure non-fatal Date: Tue, 29 Aug 2023 17:13:08 +0200 Message-ID: In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libvir-list-bounces@redhat.com Sender: "libvir-list" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 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: 1693322008455100001 Content-Type: text/plain; charset="utf-8"; x-default="true" The point of calling sysconf(_SC_OPEN_MAX) is to allocate big enough bitmap so that subsequent call to virCommandMassCloseGetFDsDir() can just set the bit instead of expanding memory (this code runs in a forked off child and thus using async-signal-unsafe functions like malloc() is a bit tricky). But on some systems the limit for opened FDs is virtually non-existent (typically macOS Ventura started reporting EINVAL). But with both glibc and musl using malloc() after fork() is safe. And with sufficiently new glib too, as it's using malloc() with newer releases instead of their own allocator. Therefore, pick a sufficiently large value (glibc falls back to 256, [1], so 1024 should be good enough) to fall back to and make the error non-fatal. 1: https://sourceware.org/git/?p=3Dglibc.git;a=3Dblob;f=3Dsysdeps/unix/sysv= /linux/getdtsz.c;h=3D4c5a6208067d2f9eaaac6dba652702fb4af9b7e3;hb=3DHEAD Signed-off-by: Michal Privoznik --- src/util/vircommand.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/src/util/vircommand.c b/src/util/vircommand.c index 822b9487f9..8c06e19723 100644 --- a/src/util/vircommand.c +++ b/src/util/vircommand.c @@ -500,7 +500,7 @@ virCommandMassCloseGetFDsDir(virBitmap *fds, return -1; } =20 - ignore_value(virBitmapSetBit(fds, fd)); + virBitmapSetBitExpand(fds, fd); } =20 if (rc < 0) @@ -544,10 +544,8 @@ virCommandMassCloseFrom(virCommand *cmd, * Therefore we can safely allocate memory here (and transitively call * opendir/readdir) without a deadlock. */ =20 - if (openmax < 0) { - virReportSystemError(errno, "%s", _("sysconf(_SC_OPEN_MAX) failed"= )); - return -1; - } + if (openmax <=3D 0) + openmax =3D 1024; =20 fds =3D virBitmapNew(openmax); =20 --=20 2.41.0