From nobody Sun Feb 8 18:32:09 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=1662990416; cv=none; d=zohomail.com; s=zohoarc; b=Frah0RC8NKsJZBCz3YHSUTv2z2pZHVGcrBcVFZD1xw5Fhk6acLm1ETDrkvnaMwKFB8oAeJk/e7MsO1AIEjqU0W8BRYBQA9az8/7sMkLVLqpp0wocnrPcu5ci29jMNSWvbh97HBD22aGZa7u8tKqxiwowYlMiHhmHIQPEFza/bvM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1662990416; 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=n9+CgvAobumcHAXSQo8X06g9d0QrfzxxZifn1XRBjJc=; b=jFDxZ2FBWJZerCMQGx6oWkXynOv8m9qGn/cOAzrYNBPSmfXBszWRNcdZtVo5kmpU49obYnkn1TRQkXXlgT934NCV7juxmA5V7fMCpUZBoea/2gC0K1WY4/gPBI1BWhbbEu4RebmWCKhXyf8KXJUZLCLdQNFknmKh+RkuncPwSps= 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 1662990416752255.59772496539517; Mon, 12 Sep 2022 06:46:56 -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-74-X_ZmLbq8NRGAPgXw4UPXcg-1; Mon, 12 Sep 2022 09:46:54 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4C5038032F6; Mon, 12 Sep 2022 13:46:52 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 906111121315; Mon, 12 Sep 2022 13:46:50 +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 73E141946A47; Mon, 12 Sep 2022 13:46:50 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id B71CD1946A53 for ; Mon, 12 Sep 2022 13:46:48 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id B2C7140C6EC2; Mon, 12 Sep 2022 13:46:48 +0000 (UTC) Received: from localhost.localdomain (unknown [10.40.193.131]) by smtp.corp.redhat.com (Postfix) with ESMTP id 213BA40C6EC5 for ; Mon, 12 Sep 2022 13:46:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1662990415; 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=n9+CgvAobumcHAXSQo8X06g9d0QrfzxxZifn1XRBjJc=; b=V3Dvk/L/5vvY+D4IjIYmJ6UdwxVF6GmsxuXCsMiSHw2LnB5sLyg0bO4tQSXrcgKNmvNLR4 pJ/YufGpQ17z1TG9P7OiFD+M1NHzxJZ7W1s+5U4HhWz8SHl9nsYj3Tn3XxifrCWB2gi1tW T4DJC05GoAEGL49l4ANNdBFUXcmTHC8= X-MC-Unique: X_ZmLbq8NRGAPgXw4UPXcg-1 X-Original-To: libvir-list@listman.corp.redhat.com From: Michal Privoznik To: libvir-list@redhat.com Subject: [PATCH 4/4] qemu_process.c: Propagate hugetlbfs mounts on reconnect Date: Mon, 12 Sep 2022 15:46:41 +0200 Message-Id: <0badb1083471e46d9975b91fd8b24ceb40ff6b4c.1662990291.git.mprivozn@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 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.3 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: 1662990418126100001 Content-Type: text/plain; charset="utf-8"; x-default="true" When reconnecting to a running QEMU process, we construct the per-domain path in all hugetlbfs mounts. This is a relict from the past (v3.4.0-100-g5b24d25062) where we switched to a per-domain path and we want to create those paths when libvirtd restarts on upgrade. And with namespaces enabled there is one corner case where the path is not created. In fact an error is reported and the reconnect fails. Ideally, all mount events are propagated into the QEMU's namespace. And they probably are, except when the target path does not exist inside the namespace. Now, it's pretty common for users to mount hugetlbfs under /dev (e.g. /dev/hugepages), but if domain is started without hugepages (or more specifically - private hugetlbfs path wasn't created on domain startup), then the reconnect code tries to create it. But it fails to do so, well, it fails to set seclabels on the path because, because the path does not exist in the private namespace. And it doesn't exist because we specifically create only a subset of all possible /dev nodes. Therefore, the mount event, whilst propagated, is not successful and hence the filesystem is not mounted. We have to do it ourselves. If hugetlbfs is mount anywhere else there's no problem and this is effectively a dead code. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=3D2123196 Signed-off-by: Michal Privoznik Reviewed-by: Martin Kletzander --- docs/kbase/qemu-passthrough-security.rst | 6 ------ src/qemu/qemu_process.c | 3 +++ 2 files changed, 3 insertions(+), 6 deletions(-) diff --git a/docs/kbase/qemu-passthrough-security.rst b/docs/kbase/qemu-pas= sthrough-security.rst index 106c3cc5b9..ef10d8af9b 100644 --- a/docs/kbase/qemu-passthrough-security.rst +++ b/docs/kbase/qemu-passthrough-security.rst @@ -172,9 +172,3 @@ command before any guest is started: :: =20 # mount --make-rshared / - -Another requirement for dynamic mount point propagation is to not place -``hugetlbfs`` mount points under ``/dev`` because these won't be propagate= d as -corresponding directories do not exist in the private namespace. Or just u= se -``memfd`` memory backend instead which does not require ``hugetlbfs`` mount -points. diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index cbfdd3bda5..b05ad059c3 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -3976,6 +3976,9 @@ qemuProcessBuildDestroyMemoryPathsImpl(virQEMUDriver = *driver, return -1; } =20 + if (qemuDomainNamespaceSetupPath(vm, path, NULL) < 0) + return -1; + if (qemuSecurityDomainSetPathLabel(driver, vm, path, true) < 0) return -1; } else { --=20 2.35.1