Re: [libvirt PATCH] qemu: Fix domain ID allocation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/31/20 3:43 PM, Ján Tomko wrote:
The rewrite to use GLib's atomic ops functions changed the behavior
of virAtomicIntInc - before it returned the pre-increment value.

Most of the callers using its value were adjusted, but the one
in qemuDriverAllocateID was not. If libvirtd would reconnect to
a running domain during startup, the next started domain would get
the same ID:

$ virsh list
  Id   Name       State
--------------------------
  1    f28live    running
  1    f28live1   running

Use the g_atomic_add function directly (as recommended in viratomic.h)
and add 1 to the result.

This also restores the usual numbering from 1 instead of 0.

Signed-off-by: Ján Tomko <jtomko@xxxxxxxxxx>
Fixes: 7b9645a7d127a374b8d1c83fdf9789706dbab2c9
---
  src/qemu/qemu_conf.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index e5051027fc..0b119cbe78 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -1858,7 +1858,7 @@ qemuSetUnprivSGIO(virDomainDeviceDefPtr dev)
int qemuDriverAllocateID(virQEMUDriverPtr driver)
  {
-    return virAtomicIntInc(&driver->lastvmid);
+    return g_atomic_int_add(&driver->lastvmid, 1) + 1;
  }

Does it makes sense to replace all virAtomic with g_atomic or do we still pretend that we care about client library and we don't crash on OOM in it?

Michal





[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux