[libvirt PATCH] qemu: Fix domain ID allocation

[Ján Tomko]

On Fri, Jan 31, 2020 at 04:33:50PM +0100, Michal Privoznik wrote:
>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 at redhat.com>
>>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 

That does make sense. It is encouraged in viratomic.h, as I said in the
commit message. The reason I did not cleanup all of them is the bugfix
nature of this patch.

>still pretend that we care about client library and we don't crash on 
>OOM in it?

I sincerely hope that none of the g_atomic functions allocate memory.

Jano

>
>Michal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200131/405931e0/attachment-0001.sig>