On Wed, Apr 24, 2024 at 14:31:10 +0530, Shaleen Bathla via Devel wrote:
> multiple parallel timedout vcpu hotunplug requests coming from qemu handled
> asynchronously by libvirt can cause data corruption as they modify
> vcpu data during refresh by libvirt.
Could you please elaborate? which two code paths hit this? Could you
please provide stack traces?
> Lock each vcpu before modification and then release the lock
>
> Signed-off-by: Shaleen Bathla <shaleen.bathla@xxxxxxxxxx>
> ---
> src/qemu/qemu_domain.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 3469f0d40c59..15ec1b0a771a 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -10084,6 +10084,7 @@ qemuDomainRefreshVcpuInfo(virDomainObj *vm,
> for (i = 0; i < maxvcpus; i++) {
> vcpu = virDomainDefGetVcpu(vm->def, i);
> vcpupriv = QEMU_DOMAIN_VCPU_PRIVATE(vcpu);
> + virObjectLock(vcpupriv);
'qemuDomainVcpuPrivate' is a 'virObject' not a 'virObjectLockable' so
this doesn't work. In fact it does nothing as virObjectLock is a no-op
(apart from printing a warning of incorrect use) if the object is not
lockable.
The vcpu private data are supposed to be guarded by the lock on the
domain object along with a modification job.
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
