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

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@entry=0x7f4ef4000d20, >>> msg=msg@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@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(a)virtuozzo.com&gt; >>> --- >>> 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