- 08 2月, 2013 4 次提交
-
-
由 John Ferlan 提交于
The qemuParseGlusterString() replaced dst->src without a VIR_FREE() of what was in there before. The qemuBuildCommandLine() did not properly free the boot_buf depending on various usages. The qemuParseCommandLineDisk() had numerous paths that didn't clean up the virDomainDiskDefPtr def properly. Adjust the logic to go through an error: label before cleanup in order to free the resource.
-
由 John Ferlan 提交于
Fix various resource leaks discovered while parsing through Valgrind output
-
由 John Ferlan 提交于
The 'virtPortInterfaceID' was not VIR_FREE()'d
-
由 John Ferlan 提交于
The 'trunk' is filled in with virXPathString() value, but was never VIR_FREE()'d.
-
- 06 2月, 2013 23 次提交
-
-
由 Eric Blake 提交于
Commit 20253560 missed uses of PCI functions in the older HAL-related code, probably because hal-devel is no longer available in latest Fedora. * src/node_device/node_device_hal.c (gather_pci_cap): Reflect function rename.
-
由 Eric Blake 提交于
We had an easy way to iterate set bits, but not for iterating cleared bits. * src/util/virbitmap.h (virBitmapNextClearBit): New prototype. * src/util/virbitmap.c (virBitmapNextClearBit): Implement it. * src/libvirt_private.syms (bitmap.h): Export it. * tests/virbitmaptest.c (test4): Test it.
-
由 John Ferlan 提交于
-
由 John Ferlan 提交于
-
由 John Ferlan 提交于
Coverity noted that in the retry logic loop if res had been set, then it could be leaked so add a VIR_FREE(res) prior to retry.
-
由 John Ferlan 提交于
-
由 John Ferlan 提交于
-
由 John Ferlan 提交于
The conditional setting of cmdout in networkBuildDhcpDaemonCommandLine() caused Coverity to complain that 'cmd' could be leaked if !cmdout. Since the function is local and only called with cmdout being passed those checks have been removed.
-
由 John Ferlan 提交于
-
由 John Ferlan 提交于
The Coverity analysis emitted a BAD_SIZEOF error when doing the math within the TRACE macro. Doing the math outside the macro keeps Coverity quiet.
-
由 John Ferlan 提交于
Keep Coverity happy by passing a pointer to 'dname' rather than the array itself. The PROBE expansion would cause a BAD_SIZEOF.
-
由 Daniel P. Berrange 提交于
-
由 Daniel P. Berrange 提交于
Annotate the fields in virQEMUDriverPtr to indicate the locking rules for their use Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Currently the activePciHostdevs, inactivePciHostdevsd and activeUsbHostdevs lists are all implicitly protected by the QEMU driver lock. Now that the lists all inherit from the virObjectLockable, we can make the locking explicit, removing the dependency on the QEMU driver lock for correctness. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
To allow modifications to the lists to be synchronized, convert virPCIDeviceList and virUSBDeviceList into virObjectLockable classes. The locking, however, will not be self-contained. The users of these classes will have to call virObjectLock/Unlock in the critical regions. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Rename all the usbDeviceXXX and usbXXXDevice APIs to have a fixed virUSBDevice name prefix
-
由 Daniel P. Berrange 提交于
When iterating over USB host devices to setup cgroups, the usbDevice object was leaked in both LXC and QEMU driers Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Rename all the pciDeviceXXX and pciXXXDevice APIs to have a fixed virPCIDevice name prefix
-
由 Daniel P. Berrange 提交于
The QEMU driver struct has a 'qemuVersion' field that was previously used to cache the version lookup from capabilities. With the recent QEMU capabilities rewrite the caching happens at a lower level so this field is pointless. Removing it avoids worries about locking when updating it. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Use atomic ops to increment nextvmid and encapsulate it in a method to prevent accidental non-atomic access
-
由 Daniel P. Berrange 提交于
Switch virDomainObjList to inherit from virObjectLockable and make all the APIs acquire/release the mutex when running. This makes virDomainObjList completely self-locking and no longer reliant on the hypervisor driver locks
-
由 Daniel P. Berrange 提交于
The duplicate VM checking should be done atomically with virDomainObjListAdd, so shoud not be a separate function. Instead just use flags to indicate what kind of checks are required. This pair, used in virDomainCreateXML: if (virDomainObjListIsDuplicate(privconn->domains, def, 1) < 0) goto cleanup; if (!(dom = virDomainObjListAdd(privconn->domains, privconn->caps, def, false))) goto cleanup; Changes to if (!(dom = virDomainObjListAdd(privconn->domains, privconn->caps, def, VIR_DOMAIN_OBJ_LIST_ADD_CHECK_LIVE, NULL))) goto cleanup; This pair, used in virDomainRestoreFlags: if (virDomainObjListIsDuplicate(privconn->domains, def, 1) < 0) goto cleanup; if (!(dom = virDomainObjListAdd(privconn->domains, privconn->caps, def, true))) goto cleanup; Changes to if (!(dom = virDomainObjListAdd(privconn->domains, privconn->caps, def, VIR_DOMAIN_OBJ_LIST_ADD_LIVE | VIR_DOMAIN_OBJ_LIST_ADD_CHECK_LIVE, NULL))) goto cleanup; This pair, used in virDomainDefineXML: if (virDomainObjListIsDuplicate(privconn->domains, def, 0) < 0) goto cleanup; if (!(dom = virDomainObjListAdd(privconn->domains, privconn->caps, def, false))) goto cleanup; Changes to if (!(dom = virDomainObjListAdd(privconn->domains, privconn->caps, def, 0, NULL))) goto cleanup;
-
由 Eric Blake 提交于
Otherwise, we get a lot of scary (but harmless) noise in the logs: 2013-02-05 15:35:48.555+0000: 8637: error : qemuMonitorJSONCheckError:353 : internal error unable to execute QEMU command 'add-fd': Parameter 'fdset-id' expects an existing fdset-id one for every qemu 1.2 binary that we probe. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONAddFd): During probe, avoid logging failures.
-
- 05 2月, 2013 11 次提交
-
-
由 Daniel P. Berrange 提交于
As a step towards making virDomainObjList thread-safe turn it into an opaque virObject, preventing any direct access to its internals. As part of this a new method virDomainObjListForEach is introduced to replace all existing usage of virHashForEach
-
由 Daniel P. Berrange 提交于
The APIs names for accessing the domain list object are very inconsistent. Rename them all to have a standard virDomainObjList prefix.
-
由 Daniel P. Berrange 提交于
Currently the virQEMUDriverPtr struct contains an wide variety of data with varying access needs. Move all the static config data into a dedicated virQEMUDriverConfigPtr object. The only locking requirement is to hold the driver lock, while obtaining an instance of virQEMUDriverConfigPtr. Once a reference is held on the config object, it can be used completely lockless since it is immutable. NB, not all APIs correctly hold the driver lock while getting a reference to the config object in this patch. This is safe for now since the config is never updated on the fly. Later patches will address this fully. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Michal Privoznik 提交于
If a compression binary prints something to stderr, currently it is discarded. However, it can contain useful data from debugging POV, so we should catch it.
-
由 Michal Privoznik 提交于
If a decompression binary prints something to stderr, currently it is discarded. However, it can contain useful data from debugging POV, so we should catch it.
-
由 Michal Privoznik 提交于
Commit 34e8f63a introduced support for catching errors from libvirt iohelper. However, at those times there wasn't such fancy API as virCommandDoAsyncIO(), so everything has to be implemented on our own. But since we do have the API now, we can use it and drop our implementation then.
-
由 Michal Privoznik 提交于
Currently, if we want to feed stdin, or catch stdout or stderr of a virCommand we have to use virCommandRun(). When using virCommandRunAsync() we have to register FD handles by hand. This may lead to code duplication. Hence, introduce an internal API, which does this automatically within virCommandRunAsync(). The intended usage looks like this: virCommandPtr cmd = virCommandNew*(...); char *buf = NULL; ... virCommandSetOutputBuffer(cmd, &buf); virCommandDoAsyncIO(cmd); if (virCommandRunAsync(cmd, NULL) < 0) goto cleanup; ... if (virCommandWait(cmd, NULL) < 0) goto cleanup; /* @buf now contains @cmd's stdout */ VIR_DEBUG("STDOUT: %s", NULLSTR(buf)); ... cleanup: VIR_FREE(buf); virCommandFree(cmd); Note, that both stdout and stderr buffers may change until virCommandWait() returns.
-
由 Peter Krempa 提交于
With this change it's easy to spot a forgotten free if a new device class is added.
-
由 Jiri Denemark 提交于
libvirt.c calls curl_global_init() if WITH_CURL is defined and thus it should be linked with libcurl. This fixes link failure in case neither xenapi nor esx driver is enabled (they are the only users of libcurl).
-
由 Martin Kletzander 提交于
QEMU is fully capable of handling VDI images and we just refuse to work with them. As qemu-img knows and supports this, there should be no problem with this addition. This is of course, just basic functionality, without searching for any backing files, etc.
-
由 Martin Kletzander 提交于
Some files have the magic shifted to some offset other than 0, so we have to support that. I also cleaned up some lines to be more readable and added missing magic for iso file format.
-
- 02 2月, 2013 2 次提交
-
-
由 Matthias Bolte 提交于
-
由 Matthias Bolte 提交于
Commit 4445e16b changed the signature of esxConnectToHost and esxConnectToVCenter by replacing the esxPrivate pointer with virConnectPtr. The esxPrivate pointer was then retrieved again from virConnectPtr's privateData. This resulted in a NULL pointer dereference, because the privateData pointer was not yet initialized at the point where esxConnectToHost and esxConnectToVCenter are called. This was fixed in commit b126715a that moved the initialization of privateData before the problematic calls. Simplify the logic by making the call to esxFreePrivate unconditional and changing esxConnectToHost and esxConnectToVCenter back to take a esxPrivate pointer directly. This allows to assign esxPrivate to the virConnectPtr's privateData pointer as one of the last steps in esxOpen making it more obvious that it is not initialized during the earlier steps of esxOpen.
-