On Wed, Feb 06, 2013 at 11:54:51 +0000, Daniel P. Berrange wrote:
> From: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
>
> 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list