Skip to content

L
libvirt

openeuler / libvirt

通知 3
Star 0
Fork 0
L
libvirt

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 11 12月, 2015 2 次提交
  3. 09 12月, 2015 21 次提交
  5. 08 12月, 2015 2 次提交
    • D
      logging: change log protocol to be more reusable · 50896b28
      由 Daniel P. Berrange 提交于 
      The current virtlogd RPC protocol provides the ability to
handle log files associated with QEMU stdout/err. The log
protocol messages take the virt driver, domain name and
use that to form a log file path. This is quite restrictive
as it prevents us re-using the same RPC protocol messages
for logging to char device backends where the filename
can be arbitrarily user specified. It is also bad because
it means we have 2 separate locations which have to decide
on logfile name.

This change alters the RPC protocol so that we pass the
desired log file path along when opening the log file
initially. Now the virt driver is exclusively in charge
of deciding the log filename
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      50896b28
    • D
      qemu: fix memory leak in opening log file · 0eafe995
      由 Daniel P. Berrange 提交于 
      The qemuDomainLogContextNew method leaks the "logfile" path
on the non-virtlogd code path.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      0eafe995
  7. 05 12月, 2015 2 次提交
  9. 04 12月, 2015 1 次提交
  11. 01 12月, 2015 1 次提交
    • W
      qemu_agent: fix deadlock in qemuProcessHandleAgentEOF · fe51174f
      由 Wang Yufei 提交于 
      If VM A is shutdown a by qemu agent at appoximately the same time
an agent EOF of VM A happened, there's a chance that deadlock may occur:

qemuProcessHandleAgentEOF in main thread
A)  priv->agent = NULL; //A happened before B

    //deadlock when we get agent lock which's held by worker thread
    qemuAgentClose(agent);

qemuDomainObjExitAgent called by qemuDomainShutdownFlags in worker thread
B)  hasRefs = virObjectUnref(priv->agent); // priv->agent is NULL,
                                           // return false
    if (hasRefs)
        virObjectUnlock(priv->agent); //agent lock will not be released here

In order to resolve, during EOF close the agent first, then set priv->agent
to NULL to fix the deadlock.

This essentially reverts commit id '1020a504'. It's also of note that commit
id '362d0477' notes a possible/rare deadlock similar to what was seen in
the monitor in commit id '25f582e3'. However, it seems interceding changes
including commit id 'd960d06f' should remove the deadlock issue.

With this change, if EOF is called:

    Get VM lock
    Check if !priv->agent || priv->beingDestroyed, then unlock VM
    Call qemuAgentClose
    Unlock VM

When qemuAgentClose is called
    Get Agent lock
    If Agent->fd open, close it
    Unlock Agent
    Unref Agent

qemuDomainObjEnterAgent
    Enter with VM lock
    Get Agent lock
    Increase Agent refcnt
    Unlock VM

After running agent command, calling qemuDomainObjExitAgent
    Enter with Agent lock
    Unref Agent
    If not last reference, unlock Agent
    Get VM lock

If we were in the middle of an EnterAgent, call Agent command, and
ExitAgent sequence and the EOF code is triggered, then the EOF code
can get the VM lock, make it's checks against !priv->agent ||
priv->beingDestroyed, and call qemuAgentClose. The CloseAgent
would wait to get agent lock. The other thread then will eventually
call ExitAgent, release the Agent lock and unref the Agent. Once
ExitAgent releases the Agent lock, AgentClose will get the Agent
Agent lock, close the fd, unlock the agent, and unref the agent.
The final unref would cause deletion of the agent.
Signed-off-by: NWang Yufei <james.wangyufei@huawei.com>
Reviewed-by: NRen Guannan <renguannan@huawei.com>
      fe51174f
  13. 30 11月, 2015 6 次提交
  15. 27 11月, 2015 2 次提交
  17. 26 11月, 2015 3 次提交