[libvirt] [PATCH] qemu: fix libvirtd crash when querying halted cpus info

[Maxim Nestratov]

15-Nov-16 14:26, Viktor Mihajlovski пишет:

> On 02.11.2016 17:29, Viktor Mihajlovski wrote:
>> On 02.11.2016 16:56, Maxim Nestratov wrote:
>>> It was introduced by commit 7a51d9ebb, which started to use
>>> monitor commands without job acquiring, which is unsafe and leads
>>> to simultaneous access to vm->mon structure by different threads.
>>>
>>> Crash backtrace is the following (shortened):
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> qemuMonitorSend (mon=mon at entry=0x7f4ef4000d20, msg=msg at entry=0x7f4f18e78640) at qemu/qemu_monitor.c:1011
>>> 1011        while (!mon->msg->finished) {
>>>
>>> 0  qemuMonitorSend () at qemu/qemu_monitor.c:1011
>>> 1  0x00007f691abdc720 in qemuMonitorJSONCommandWithFd () at qemu/qemu_monitor_json.c:298
>>> 2  0x00007f691abde64a in qemuMonitorJSONCommand at qemu/qemu_monitor_json.c:328
>>> 3  qemuMonitorJSONQueryCPUs at qemu/qemu_monitor_json.c:1408
>>> 4  0x00007f691abcaebd in qemuMonitorGetCPUInfo g at entry=false) at qemu/qemu_monitor.c:1931
>>> 5  0x00007f691ab96863 in qemuDomainRefreshVcpuHalted at qemu/qemu_domain.c:6309
>>> 6  0x00007f691ac0af99 in qemuDomainGetStatsVcpu at qemu/qemu_driver.c:18945
>>> 7  0x00007f691abef921 in qemuDomainGetStats  at qemu/qemu_driver.c:19469
>>> 8  qemuConnectGetAllDomainStats at qemu/qemu_driver.c:19559
>>> 9  0x00007f693382e806 in virConnectGetAllDomainStats at libvirt-domain.c:11546
>>> 10 0x00007f6934470c40 in remoteDispatchConnectGetAllDomainStats at remote.c:6267
>>>
>>> (gdb) p mon->msg
>>> $1 = (qemuMonitorMessagePtr) 0x0
>>>
>>> This change fixes it by calling qemuDomainRefreshVcpuHalted only when job is acquired.
>>>
>>> Signed-off-by: Maxim Nestratov <mnestratov at virtuozzo.com>
>>> ---
>>>   src/qemu/qemu_driver.c | 20 +++++++++++++-------
>>>   1 file changed, 13 insertions(+), 7 deletions(-)
>> [...]
>> Argh ... this fell through the cracks when I moved the code from
>> vcpuinfo to domstats. Thanks for catching and fixing that one.
>>
> It would be nice if the fix could be pushed before the next release
> freeze. Thanks!
>
I regard your reply as ACK then.
Let's wait a bit to let people react to this and if there is no objection, I'll push shortly.

Maxim