search for: virhashforeach

❦ 4 avril 2018 15:19 +0200, Michal Privoznik <mprivozn@redhat.com> : > Both threads call virHashForEach(table=0x7f92fc69a480). Thread 6 was > first so it starts iterating and sets table->iterating so later when > thread 10 enters the function an error is reported. > > I guess we can go with what Dan suggested and after some rework we can > just drop ->iterating completely. I may...

On 04/04/2018 10:36 AM, Vincent Bernat wrote: > Hey! > > On many of our servers, we often have the following error: > > error : virHashForEach:597 : Hash operation not allowed during iteration > > When querying the list of domains, this means libvirt will silently > return 0 domain (most uses of virHashForEach don't handle the return > code). > > We are using a hook, but the hook doesn't query libvirt back, so...

On 04/04/2018 03:48 PM, Vincent Bernat wrote: > ❦ 4 avril 2018 15:19 +0200, Michal Privoznik <mprivozn@redhat.com> : > >> Both threads call virHashForEach(table=0x7f92fc69a480). Thread 6 was >> first so it starts iterating and sets table->iterating so later when >> thread 10 enters the function an error is reported. >> >> I guess we can go with what Dan suggested and after some rework we can >> just drop ->iteratin...

Hey! On many of our servers, we often have the following error: error : virHashForEach:597 : Hash operation not allowed during iteration When querying the list of domains, this means libvirt will silently return 0 domain (most uses of virHashForEach don't handle the return code). We are using a hook, but the hook doesn't query libvirt back, so it should be safe from this po...

...a bt'. That might shed more light into > the issue. Smells like we are not locking somewhere properly. So, we have two threads iterating. Both of them originates from virNetServerProgramDispatchCall. So, it seems there is a lock missing? Thread 10 (Thread 0x7f931f814700 (LWP 126453)): #0 virHashForEach (table=0x7f92fc69a480, iter=iter@entry=0x7f932ea8fbf0 <virDomainObjListCollectIterator>, data=data@entry=0x7f931f813a20) at ../../../src/util/virhash.c:597 #1 0x00007f932ea911c3 in virDomainObjListCollect (domlist=0x7f92fc82dd50, conn=conn@entry=0x7f92e0000f80, vms=vms@entry=0x7f931f813a80,...

...from > virNetServerProgramDispatchCall. So, it seems there is a lock missing? No. As suspected, both threads are reading internal list of domains (actually hash table). They are not modifying the list so they grab a read lock. > > Thread 10 (Thread 0x7f931f814700 (LWP 126453)): > #0 virHashForEach (table=0x7f92fc69a480, iter=iter@entry=0x7f932ea8fbf0 <virDomainObjListCollectIterator>, data=data@entry=0x7f931f813a20) at ../../../src/util/virhash.c:597 > #1 0x00007f932ea911c3 in virDomainObjListCollect (domlist=0x7f92fc82dd50, conn=conn@entry=0x7f92e0000f80, vms=vms@entry=0x7f931f813...

...> : >> I may have missed this suggestion. Maybe Dan only sent it to you? > > No, there is another thread where this issue is discussed: > > https://www.redhat.com/archives/libvir-list/2018-April/msg00190.html > > In the >> meantime, could I change the locks around virHashForEach() and similar >> as read/write locks? >> > > You can do that locally, but as a patch it's very unlikely to be > accepted upstream because we've introduced RW locks to be able to access > domain list from multiple threads. Looking a bit more, the whole "iterati...

❦ 4 avril 2018 16:21 +0200, Vincent Bernat <bernat@luffy.cx> : >> You can do that locally, but as a patch it's very unlikely to be >> accepted upstream because we've introduced RW locks to be able to access >> domain list from multiple threads. > > Looking a bit more, the whole "iterating" bit is currently > unsafe. First, it is racy since

❦ 4 avril 2018 17:00 +0200, Vincent Bernat <bernat@luffy.cx> : >>> You can do that locally, but as a patch it's very unlikely to be >>> accepted upstream because we've introduced RW locks to be able to access >>> domain list from multiple threads. >> >> Looking a bit more, the whole "iterating" bit is currently >> unsafe.

On 04/04/2018 08:38 PM, Vincent Bernat wrote: > 0001-util-don-t-check-for-parallel-iteration-in-hash-rela.patch > > > From 7bf32825325b124edce58687a8cd2ceff13328b9 Mon Sep 17 00:00:00 2001 > From: Vincent Bernat <vincent@bernat.im> > Date: Wed, 4 Apr 2018 16:25:37 +0200 > Subject: [PATCH] util: don't check for parallel iteration in hash-related > functions Can

❦ 5 avril 2018 17:00 +0200, Michal Privoznik <mprivozn@redhat.com> : >> 0001-util-don-t-check-for-parallel-iteration-in-hash-rela.patch >> >> >> From 7bf32825325b124edce58687a8cd2ceff13328b9 Mon Sep 17 00:00:00 2001 >> From: Vincent Bernat <vincent@bernat.im> >> Date: Wed, 4 Apr 2018 16:25:37 +0200 >> Subject: [PATCH] util: don't check

...ption of domain hashtable and misuse of freed domains (Laine Stump) - qemu: Add missing lock of virDomainObj before calling virDomainUnref (Laine Stump) - esx: Escape password for XML (Matthias Bolte) - util: correct retry path in virFileOperation (Eric Blake) - util: Allow removing hash entries in virHashForEach (Jiri Denemark) - qemu: avoid double close on domain restore (Eric Blake) - Fix port value parsing for serial and parallel ports (Michal Novotny) - Fix off-by-1 in virFileAbsPath. (Daniel P. Berrange) - security: avoid memory leak (Eric Blake) - protect the scsi controller to be deleted when it is...