[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] Introduction of virDomainDefPtr resulted in deadlock in xenUnifiedDomainGetXMLDesc



The problem is the mutex lock on xenUnifiedPrivatePtr which is held around
xenDomainUsedCpus.

xenUnifiedDomainGetXMLDesc
  ...
  xenUnifiedLock(priv);
  cpus = xenDomainUsedCpus(dom);
  xenUnifiedUnlock(priv);
  ...

Unfortunately the introduction of virDomainDefPtr added the following call paths

xenDomainUsedCpus
  ...
  nb_vcpu = xenUnifiedDomainGetMaxVcpus(dom);
    return xenUnifiedDomainGetVcpusFlags(...)
      ...
      if (!(def = xenGetDomainDefForDom(dom)))
        return xenGetDomainDefForUUID(dom->conn, dom->uuid);
          ...
          ret = xenHypervisorLookupDomainByUUID(conn, uuid);
            ...
            xenUnifiedLock(priv);
            name = xenStoreDomainGetName(conn, id);
            xenUnifiedUnlock(priv);
  ...
  if ((ncpus = xenUnifiedDomainGetVcpus(dom, cpuinfo, nb_vcpu,
    ...
    if (!(def = xenGetDomainDefForDom(dom)))
      [again like above]

Right now, running the GetXMLDesc command for an active Xen domain will lock up
right in the xenUnifiedDomainGetMaxVcpus call. But any subcall leading to a call
to xenGetDomainDefForDom while holding the xenUnifiedPrivatePtr lock will have
the same fate.

I assume the lock around the xenDomainUsedCpus call is there to ensure all
accesses to the private pointer see consistent data. Otherwise it would be
possible to simply release the lock before the GetMaxVcpus and GetVcpus calls.

If that lock cannot be dropped this feels like a much more painful rework is needed.

What do others think?

-Stefan

Attachment: signature.asc
Description: OpenPGP digital signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]