- 23 4月, 2018 1 次提交
-
-
由 John Ferlan 提交于
Now that every caller is using virDomainObjListFindByUUIDRef, let's just remove it and keep the name as virDomainObjListFindByUUID. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NJim Fehlig <jfehlig@suse.com>
-
- 18 4月, 2018 1 次提交
-
-
由 Michal Privoznik 提交于
So far we are repeating the following lines over and over: if (!(virSomeObjectClass = virClassNew(virClassForObject(), "virSomeObject", sizeof(virSomeObject), virSomeObjectDispose))) return -1; While this works, it is impossible to do some checking. Firstly, the class name (the 2nd argument) doesn't match the name in the code in all cases (the 3rd argument). Secondly, the current style is needlessly verbose. This commit turns example into following: if (!(VIR_CLASS_NEW(virSomeObject, virClassForObject))) return -1; Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
-
- 10 4月, 2018 1 次提交
-
-
由 John Ferlan 提交于
Since virCloseCallbacksRun was ignoring the value anyway, let's just change it to be a void function. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> Reviewed-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
-
- 04 2月, 2017 1 次提交
-
-
由 John Ferlan 提交于
Originally/discovered proposed by "Wang King <king.wang@huawei.com>" When the virCloseCallbacksSet is first called, it increments the refcnt on the domain object to ensure it doesn't get deleted before the callback is called. The refcnt would be decremented in virCloseCallbacksUnset once the entry is removed from the closeCallbacks has table. When (mostly) normal shutdown occurs, the qemuProcessStop will end up calling qemuProcessAutoDestroyRemove and will remove the callback from the list and hash table normally and decrement the refcnt. However, when qemuConnectClose calls virCloseCallbacksRun, it will scan the (locked) closeCallbacks list for matching domain and callback function. If an entry is found, it will be removed from the closeCallbacks list and placed into a lookaside list to be processed when the closeCallbacks lock is dropped. The callback function (e.g. qemuProcessAutoDestroy) is called and will run qemuProcessStop. That code will fail to find the callback in the list when qemuProcessAutoDestroyRemove is called and thus not decrement the domain refcnt. Instead since the entry isn't found the code will just return (mostly) harmlessly. This patch will resolve the issue by taking another ref during the search UUID process during virCloseCallackRun, decrementing the refcnt taken by virCloseCallbacksSet, calling the callback routine and returning overwriting the vm (since it could return NULL). Finally, it will call the virDomainObjEndAPI to lower the refcnt and remove the lock taken during the search UUID processing. This may cause the vm to be destroyed.
-
- 22 1月, 2017 2 次提交
-
-
由 John Ferlan 提交于
Should be Unlock not Lock... Bad fingers.
-
由 Wang King 提交于
Avoid return with the closeCallbacks locked when get callbacks list for connect fail. Signed-off-by: NWang King <king.wang@huawei.com> Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
-
- 07 9月, 2016 1 次提交
-
-
由 Maxim Nestratov 提交于
There is a possibility that qemu driver frees by unreferencing its closeCallbacks pointer as it has the only reference to the object, while in fact not all users of CloseCallbacks called thier virCloseCallbacksUnset. Backtrace is the following: Thread #1: 0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 1 in virCondWait (c=<optimized out>, m=<optimized out>) at util/virthread.c:154 2 in virThreadPoolFree (pool=0x7f0810110b50) at util/virthreadpool.c:266 3 in qemuStateCleanup () at qemu/qemu_driver.c:1116 4 in virStateCleanup () at libvirt.c:808 5 in main (argc=<optimized out>, argv=<optimized out>) at libvirtd.c:1660 Thread #2: 0 in virClassIsDerivedFrom (klass=0xdeadbeef, parent=0x7f0837c694d0) at util/virobject.c:169 1 in virObjectIsClass (anyobj=anyobj@entry=0x7f08101d4760, klass=<optimized out>) at util/virobject.c:365 2 in virObjectLock (anyobj=0x7f08101d4760) at util/virobject.c:317 3 in virCloseCallbacksUnset (closeCallbacks=0x7f08101d4760, vm=vm@entry=0x7f08101d47b0, cb=cb@entry=0x7f081d078fc0 <qemuProcessAutoDestroy>) at util/virclosecallbacks.c:163 4 in qemuProcessAutoDestroyRemove (driver=driver@entry=0x7f081018be50, vm=vm@entry=0x7f08101d47b0) at qemu/qemu_process.c:6368 5 in qemuProcessStop (driver=driver@entry=0x7f081018be50, vm=vm@entry=0x7f08101d47b0, reason=reason@entry=VIR_DOMAIN_SHUTOFF_SHUTDOWN, asyncJob=asyncJob@entry=QEMU_ASYNC_JOB_NONE, flags=flags@entry=0) at qemu/qemu_process.c:5854 6 in processMonitorEOFEvent (vm=0x7f08101d47b0, driver=0x7f081018be50) at qemu/qemu_driver.c:4585 7 qemuProcessEventHandler (data=<optimized out>, opaque=0x7f081018be50) at qemu/qemu_driver.c:4629 8 in virThreadPoolWorker (opaque=opaque@entry=0x7f0837c4f820) at util/virthreadpool.c:145 9 in virThreadHelper (data=<optimized out>) at util/virthread.c:206 10 in start_thread () from /lib64/libpthread.so.0 Let's reference CloseCallbacks object in virCloseCallbacksSet and unreference in virCloseCallbacksUnset. Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>
-
- 17 2月, 2016 1 次提交
-
-
由 Erik Skultety 提交于
Our existing virHashForEach method iterates through all items disregarding the fact, that some of the iterators might have actually failed. Errors are usually dispatched through an error element in opaque data which then causes the original caller of virHashForEach to return -1. In that case, virHashForEach could return as soon as one of the iterators fail. This patch changes the iterator return type and adjusts all of its instances accordingly, so the actual refactor of virHashForEach method can be dealt with later. Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 08 4月, 2015 1 次提交
-
-
由 Michael Chapman 提交于
The close callbacks hash are keyed by a UUID-string, but virCloseCallbacksRun was attempting to remove them by raw UUID. This patch ensures the callback entries are removed by UUID-string as well. This bug caused problems when guest migrations were abnormally aborted: # timeout --signal KILL 1 \ virsh migrate example qemu+tls://remote/system \ --verbose --compressed --live --auto-converge \ --abort-on-error --unsafe --persistent \ --undefinesource --copy-storage-all --xml example.xml Killed # virsh migrate example qemu+tls://remote/system \ --verbose --compressed --live --auto-converge \ --abort-on-error --unsafe --persistent \ --undefinesource --copy-storage-all --xml example.xml error: Requested operation is not valid: domain 'example' is not being migrated Signed-off-by: NMichael Chapman <mike@very.puzzling.org>
-
- 21 12月, 2014 1 次提交
-
-
由 Martin Kletzander 提交于
There is one problem that causes various errors in the daemon. When domain is waiting for a job, it is unlocked while waiting on the condition. However, if that domain is for example transient and being removed in another API (e.g. cancelling incoming migration), it get's unref'd. If the first call, that was waiting, fails to get the job, it unref's the domain object, and because it was the last reference, it causes clearing of the whole domain object. However, when finishing the call, the domain must be unlocked, but there is no way for the API to know whether it was cleaned or not (unless there is some ugly temporary variable, but let's scratch that). The root cause is that our APIs don't ref the objects they are using and all use the implicit reference that the object has when it is in the domain list. That reference can be removed when the API is waiting for a job. And because each domain doesn't do its ref'ing, it results in the ugly checking of the return value of virObjectUnref() that we have everywhere. This patch changes qemuDomObjFromDomain() to ref the domain (using virDomainObjListFindByUUIDRef()) and adds qemuDomObjEndAPI() which should be the only function in which the return value of virObjectUnref() is checked. This makes all reference counting deterministic and makes the code a bit clearer. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 07 4月, 2014 1 次提交
-
-
由 Eric Blake 提交于
I almost wrote a hash value free function that just called VIR_FREE, then realized I couldn't be the first person to do that. Sure enough, it was worth factoring into a common helper routine. * src/util/virhash.h (virHashValueFree): New function. * src/util/virhash.c (virHashValueFree): Implement it. * src/util/virobject.h (virObjectFreeHashData): New function. * src/libvirt_private.syms (virhash.h, virobject.h): Export them. * src/nwfilter/nwfilter_learnipaddr.c (virNWFilterLearnInit): Use common function. * src/qemu/qemu_capabilities.c (virQEMUCapsCacheNew): Likewise. * src/qemu/qemu_command.c (qemuDomainCCWAddressSetCreate): Likewise. * src/qemu/qemu_monitor.c (qemuMonitorGetBlockInfo): Likewise. * src/qemu/qemu_process.c (qemuProcessWaitForMonitor): Likewise. * src/util/virclosecallbacks.c (virCloseCallbacksNew): Likewise. * src/util/virkeyfile.c (virKeyFileParseGroup): Likewise. * tests/qemumonitorjsontest.c (testQemuMonitorJSONqemuMonitorJSONGetBlockInfo): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 25 3月, 2014 1 次提交
-
-
由 Ján Tomko 提交于
-
- 18 3月, 2014 1 次提交
-
-
由 Daniel P. Berrange 提交于
Any source file which calls the logging APIs now needs to have a VIR_LOG_INIT("source.name") declaration at the start of the file. This provides a static variable of the virLogSource type. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 18 7月, 2013 2 次提交
-
-
由 Michal Privoznik 提交于
-
由 Michal Privoznik 提交于
-