On Wed, Feb 06, 2013 at 11:54:51 +0000, Daniel P. Berrange wrote:
From: "Daniel P. Berrange" <berrange@redhat.com>
The 'driver->caps' pointer can be changed on the fly. Accessing it currently requires the global driver lock. Isolate this access in a single helper, so a future patch can relax the locking constraints. ... I checked that no direct access to driver->caps remained.
There are quite a few places where virQEMUDriverGetCapabilities is called on an unlocked driver but that's not your fault. The bug has been there even for years in some cases. Anyway, I guess one of your next series will fix all these issues by changing the way we use qemu driver lock. ...
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 18c4d3c..7ada7c3 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c ... @@ -956,20 +888,25 @@ static void qemuNotifyLoadDomain(virDomainObjPtr vm, int newVM, void *opaque) static int qemuReload(void) { virQEMUDriverConfigPtr cfg; + virCapsPtr caps;
if (!qemu_driver) return 0;
+ if (!(caps = virQEMUDriverGetCapabilities(qemu_driver, false))) + return -1; +
I know you're going to revisit qemu_driver locking in a future series but you can still add virQEMUDriverGetCapabilities call after qemu_driver is actually locked here.
qemuDriverLock(qemu_driver); cfg = virQEMUDriverGetConfig(qemu_driver); virDomainObjListLoadAllConfigs(qemu_driver->domains, - qemu_driver->caps, + caps, cfg->configDir, cfg->autostartDir, 0, QEMU_EXPECTED_VIRT_TYPES, qemuNotifyLoadDomain, qemu_driver); qemuDriverUnlock(qemu_driver); virObjectUnref(cfg); + virObjectUnref(caps); return 0; }
... ACK with this small change. Jirka