dc2b6e
From 2aeb222d9d61868ef40932b4349af84696415e11 Mon Sep 17 00:00:00 2001
dc2b6e
Message-Id: <2aeb222d9d61868ef40932b4349af84696415e11@dist-git>
dc2b6e
From: Michal Privoznik <mprivozn@redhat.com>
dc2b6e
Date: Tue, 6 Sep 2022 13:45:51 +0200
dc2b6e
Subject: [PATCH] qemu_process.c: Propagate hugetlbfs mounts on reconnect
dc2b6e
dc2b6e
When reconnecting to a running QEMU process, we construct the
dc2b6e
per-domain path in all hugetlbfs mounts. This is a relict from
dc2b6e
the past (v3.4.0-100-g5b24d25062) where we switched to a
dc2b6e
per-domain path and we want to create those paths when libvirtd
dc2b6e
restarts on upgrade.
dc2b6e
dc2b6e
And with namespaces enabled there is one corner case where the
dc2b6e
path is not created. In fact an error is reported and the
dc2b6e
reconnect fails. Ideally, all mount events are propagated into
dc2b6e
the QEMU's namespace. And they probably are, except when the
dc2b6e
target path does not exist inside the namespace. Now, it's pretty
dc2b6e
common for users to mount hugetlbfs under /dev (e.g.
dc2b6e
/dev/hugepages), but if domain is started without hugepages (or
dc2b6e
more specifically - private hugetlbfs path wasn't created on
dc2b6e
domain startup), then the reconnect code tries to create it.
dc2b6e
But it fails to do so, well, it fails to set seclabels on the
dc2b6e
path because, because the path does not exist in the private
dc2b6e
namespace. And it doesn't exist because we specifically create
dc2b6e
only a subset of all possible /dev nodes. Therefore, the mount
dc2b6e
event, whilst propagated, is not successful and hence the
dc2b6e
filesystem is not mounted. We have to do it ourselves.
dc2b6e
dc2b6e
If hugetlbfs is mount anywhere else there's no problem and this
dc2b6e
is effectively a dead code.
dc2b6e
dc2b6e
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2123196
dc2b6e
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
dc2b6e
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
dc2b6e
(cherry picked from commit 0377177c7856bb87a9d8aa1324b54f5fbe9f1e5b)
dc2b6e
dc2b6e
Conflicts:
dc2b6e
- docs/kbase/qemu-passthrough-security.rst: Well, v8.8.0-rc1~32
dc2b6e
  isn't backported, thus we can't remove a paragraph that the
dc2b6e
  backported commit did. It's a documentation after all, so no
dc2b6e
  harm.
dc2b6e
dc2b6e
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2123196
dc2b6e
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
dc2b6e
---
dc2b6e
 src/qemu/qemu_process.c | 3 +++
dc2b6e
 1 file changed, 3 insertions(+)
dc2b6e
dc2b6e
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
dc2b6e
index 540eee9ff0..1164340aa9 100644
dc2b6e
--- a/src/qemu/qemu_process.c
dc2b6e
+++ b/src/qemu/qemu_process.c
dc2b6e
@@ -3906,6 +3906,9 @@ qemuProcessBuildDestroyMemoryPathsImpl(virQEMUDriver *driver,
dc2b6e
             return -1;
dc2b6e
         }
dc2b6e
 
dc2b6e
+        if (qemuDomainNamespaceSetupPath(vm, path, NULL) < 0)
dc2b6e
+            return -1;
dc2b6e
+
dc2b6e
         if (qemuSecurityDomainSetPathLabel(driver, vm, path, true) < 0)
dc2b6e
             return -1;
dc2b6e
     } else {
dc2b6e
-- 
dc2b6e
2.38.0
dc2b6e