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

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(a)redhat.com&gt; >> 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.