PCI-Multifunction hotplug support #1

ShivaprasadGBhat · 2016-09-09T18:42:50Z

No description provided.

Fix xlconfigtest runs build for --enable-test-oom on Xen XL-2-XML Parse channel-pty Program received signal SIGSEGV, Segmentation fault. #0 0x00007ffff3c2b373 in __strchr_sse2 () from /lib64/libc.so.6 ==> #1 0x00007ffff7875701 in virConfSaveValue (buf=buf@entry=0x7fffffffd8a0, val=val@entry=0x674750) at util/virconf.c:290 #2 0x00007ffff7875668 in virConfSaveValue (buf=buf@entry=0x7fffffffd8a0, val=<optimized out>) at util/virconf.c:306 #3 0x00007ffff78757ef in virConfSaveEntry (buf=buf@entry=0x7fffffffd8a0, cur=cur@entry=0x674780) at util/virconf.c:338 #4 0x00007ffff78783eb in virConfWriteMem (memory=0x665570 "", len=len@entry=0x7fffffffd910, conf=conf@entry=0x65b940) at util/virconf.c:1543 #5 0x000000000040eccb in testCompareParseXML (replaceVars=<optimized out>, xml=<optimized out>, xlcfg=0x662c00 "/home/wtenhave/WORK/libvirt/OOMtesting/libvirt-devel/tests/xlconfigdata/test-channel-pty.cfg") at xlconfigtest.c:108 #6 testCompareHelper (data=<optimized out>) at xlconfigtest.c:205 #7 0x0000000000410b3a in virTestRun (title=title@entry=0x432cc0 "Xen XL-2-XML Parse channel-pty", body=body@entry=0x40e9b0 <testCompareHelper>, data=data@entry=0x7fffffffd9f0) at testutils.c:247 #8 0x000000000040f322 in mymain () at xlconfigtest.c:278 #9 0x0000000000411410 in virTestMain (argc=1, argv=0x7fffffffdba8, func=0x40f660 <mymain>) at testutils.c:992 #10 0x00007ffff3bc0401 in __libc_start_main () from /lib64/libc.so.6 #11 0x000000000040e86a in _start () (gdb) frame 1 #1 0x00007ffff7875701 in virConfSaveValue (buf=buf@entry=0x7fffffffd8a0, val=val@entry=0x674750) at util/virconf.c:290 290 if (strchr(val->str, '\n') != NULL) { (gdb) print *val $1 = {type = VIR_CONF_STRING, next = 0x0, l = 0, str = 0x0, list = 0x0} Signed-off-by: Wim ten Have <[email protected]>

Fix xlconfigtest runs build for --enable-test-oom on Xen XL-2-XML Parse new-disk #0 0x00007ffff3bd791f in raise () from /lib64/libc.so.6 #1 0x00007ffff3bd951a in abort () from /lib64/libc.so.6 #2 0x00007ffff3c1b200 in __libc_message () from /lib64/libc.so.6 #3 0x00007ffff3c2488a in _int_free () from /lib64/libc.so.6 #4 0x00007ffff3c282bc in free () from /lib64/libc.so.6 #5 0x00007ffff7864fcb in virFree (ptrptr=ptrptr@entry=0x7fffffffd868) at util/viralloc.c:582 #6 0x00007ffff78776e5 in virConfFreeValue (val=<optimized out>) at util/virconf.c:178 ==> #7 0x0000000000425759 in xenFormatXLDomainDisks (def=0x7fffffffd8c0, def=0x7fffffffd8c0, conf=0x658220) at xenconfig/xen_xl.c:1159 #8 xenFormatXL (def=def@entry=0x66ec20, conn=conn@entry=0x668cf0) at xenconfig/xen_xl.c:1558 #9 0x000000000040ea1d in testCompareParseXML (replaceVars=<optimized out>, xml=0x65f5e0 "/home/wtenhave/WORK/libvirt/history/libvirt/tests/xlconfigdata/test-fullvirt-ovmf.xml", xlcfg=0x65f6b0 "/home/wtenhave/WORK/libvirt/history/libvirt/tests/xlconfigdata/test-fullvirt-ovmf.cfg") at xlconfigtest.c:105 #10 testCompareHelper (data=<optimized out>) at xlconfigtest.c:205 #11 0x000000000041079a in virTestRun (title=title@entry=0x431cf0 "Xen XL-2-XML Parse fullvirt-ovmf", body=body@entry=0x40e720 <testCompareHelper>, data=data@entry=0x7fffffffda50) at testutils.c:247 #12 0x000000000040ebc2 in mymain () at xlconfigtest.c:256 #13 0x0000000000411070 in virTestMain (argc=1, argv=0x7fffffffdc08, func=0x40f2c0 <mymain>) at testutils.c:992 #14 0x00007ffff3bc2401 in __libc_start_main () from /lib64/libc.so.6 #15 0x000000000040e5da in _start () symmetry seems missing its sibbling coded functionality demonstrated under functions; xenFormatXLUSBController() xenFormatXLUSB() xenFormatXLDomainChannels() xenFormatXMDisks Signed-off-by: Wim ten Have <[email protected]>

Fix xlconfig channel tests when OOM testing is enabled. TEST: xlconfigtest 32) Xen XL-2-XML Format channel-unix ... OK Test OOM for nalloc=55 ................................................*** Error in `/home/jfehlig/virt/upstream/libvirt/tests/.libs/xlconfigtest': double free or corruption (fasttop): 0x0000000000679550 *** ... (gdb) bt #0 0x00007ffff36875af in raise () from /lib64/libc.so.6 #1 0x00007ffff36889aa in abort () from /lib64/libc.so.6 #2 0x00007ffff36c5150 in __libc_message () from /lib64/libc.so.6 #3 0x00007ffff36cb4f6 in malloc_printerr () from /lib64/libc.so.6 #4 0x00007ffff36cbcee in _int_free () from /lib64/libc.so.6 #5 0x00007ffff782babf in virFree (ptrptr=0x7fffffffdca8) at util/viralloc.c:582 #6 0x000000000042f2f3 in xenParseXLChannel (conf=0x677350, def=0x6815b0) at xenconfig/xen_xl.c:788 #7 0x000000000042f44e in xenParseXL (conf=0x677350, caps=0x6832b0, xmlopt=0x67f6e0) at xenconfig/xen_xl.c:828 #8 0x00000000004105a3 in testCompareFormatXML ( xlcfg=0x6811e0 "/home/jfehlig/virt/upstream/libvirt/tests/xlconfigdata/test-channel-unix.cfg", xml=0x681110 "/home/jfehlig/virt/upstream/libvirt/tests/xlconfigdata/test-channel-unix.xml", replaceVars=false) at xlconfigtest.c:152 When a channel is successfully parsed and its path and name fields assigned from local variables, set the local variables to NULL to prevent a double free on error. Signed-off-by: Jim Fehlig <[email protected]>

ka maybe have been freeed in virObjectUnref, application using virKeepAliveTimer will segfault when unlock ka. We should keep ka's refs positive before using it. #0 0x00007fd8f79970e8 in virClassIsDerivedFrom (klass=0xdeadbeef, parent=0x7fd8e8001b80) at util/virobject.c:169 #1 0x00007fd8f799742e in virObjectIsClass (anyobj=anyobj entry=0x7fd8e800b9c0, klass=＜optimized out＞) at util/virobject.c:365 #2 0x00007fd8f79974e4 in virObjectUnlock (anyobj=0x7fd8e800b9c0) at util/virobject.c:338 #3 0x00007fd8f7ac477e in virKeepAliveTimer (timer=＜optimized out＞, opaque=0x7fd8e800b9c0) at rpc/virkeepalive.c:177 #4 0x00007fd8f7e5c9cf in libvirt_virEventInvokeTimeoutCallback () from /usr/lib64/python2.7/site-packages/libvirtmod.so #5 0x00007fd8ff64db94 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #6 0x00007fd8ff64f1ad in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0 #7 0x00007fd8ff64d85f in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #8 0x00007fd8ff64d950 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #9 0x00007fd8ff64d950 in PyEval_EvalFrameEx () from /lib64/libpython2.7.so.1.0 #10 0x00007fd8ff64f1ad in PyEval_EvalCodeEx () from /lib64/libpython2.7.so.1.0 #11 0x00007fd8ff5dc098 in function_call () from /lib64/libpython2.7.so.1.0 #12 0x00007fd8ff5b7073 in PyObject_Call () from /lib64/libpython2.7.so.1.0 #13 0x00007fd8ff5c6085 in instancemethod_call () from /lib64/libpython2.7.so.1.0 #14 0x00007fd8ff5b7073 in PyObject_Call () from /lib64/libpython2.7.so.1.0 #15 0x00007fd8ff648ff7 in PyEval_CallObjectWithKeywords () from /lib64/libpython2.7.so.1.0 #16 0x00007fd8ff67d7e2 in t_bootstrap () from /lib64/libpython2.7.so.1.0 #17 0x00007fd8ff358df3 in start_thread () from /lib64/libpthread.so.0 #18 0x00007fd8fe97d3ed in clone () from /lib64/libc.so.6 Signed-off-by: Yi Wang <[email protected]> Signed-off-by: Michal Privoznik <[email protected]>

Based upon an idea and some research by Wang King <[email protected]> and xinhua.Cao <[email protected]>. Since we're assigning the 'client' to our callback event lookaside list, it's imperative that we grab a reference to the object; otherwise, when the object is unref'd during virNetServerProcessClients when it's determined that the virNetServerClientIsClosed and the memory is free'd before perhaps the object event state callbacks are run. When a virObjectLock() is run, before sending the message the following trace occurs; #0 0x00007fda223d66d8 in virClassIsDerivedFrom (klass=0xdeadbeef, parent=0x7fda24c81b40) at util/virobject.c:169 #1 0x00007fda223d6a1e in virObjectIsClass (anyobj=anyobj@entry=0x7fd9e575b400, klass=<optimized out>) at util/virobject.c:365 #2 0x00007fda223d6a44 in virObjectLock (anyobj=0x7fd9e575b400) at util/virobject.c:317 #3 0x00007fda22507f71 in virNetServerClientSendMessage (client=client@entry=0x7fd9e575b400, msg=msg@entry=0x7fd9ec30de90) at rpc/virnetserverclient.c:1422 #4 0x00007fda230d714d in remoteDispatchObjectEventSend (client=0x7fd9e575b400, program=0x7fda24c844e0, procnr=348, proc=0x7fda2310e5e0 <xdr_remote_domain_event_callback_tunable_msg>, data=0x7ffc3857fdb0) at remote.c:3803 #5 0x00007fda230dd71b in remoteRelayDomainEventTunable (conn=<optimized out>, dom=0x7fda27cd7660, params=0x7fda27f3aae0, nparams=1,opaque=0x7fd9e6c99e00) at remote.c:1033 #6 0x00007fda224484cb in virDomainEventDispatchDefaultFunc (conn=0x7fda27cd0120, event=0x7fda2736ea00, cb=0x7fda230dd610 <remoteRelayDomainEventTunable>, cbopaque=0x7fd9e6c99e00) at conf/domain_event.c:1910 #7 0x00007fda22446871 in virObjectEventStateDispatchCallbacks (callbacks=<optimized out>, callbacks=<optimized out>, event=0x7fda2736ea00,state=0x7fda24ca3960) at conf/object_event.c:722 #8 virObjectEventStateQueueDispatch (callbacks=0x7fda24c65800, queue=0x7ffc3857fe90, state=0x7fda24ca3960) at conf/object_event.c:736 #9 virObjectEventStateFlush (state=0x7fda24ca3960) at conf/object_event.c:814 #10 virObjectEventTimer (timer=<optimized out>, opaque=0x7fda24ca3960) at conf/object_event.c:560 #11 0x00007fda223ae8b9 in virEventPollDispatchTimeouts () at util/vireventpoll.c:458 #12 virEventPollRunOnce () at util/vireventpoll.c:654 #13 0x00007fda223ad1d2 in virEventRunDefaultImpl () at util/virevent.c:314 #14 0x00007fda225046cd in virNetDaemonRun (dmn=0x7fda24c775c0) at rpc/virnetdaemon.c:818 #15 0x00007fda230d6351 in main (argc=<optimized out>, argv=<optimized out>) at libvirtd.c:1623 Signed-off-by: John Ferlan <[email protected]>

@freeCB

If a remote call fails during event registration (more than likely from a network failure or remote libvirtd restart timed just right), then when calling the virObjectEventStateDeregisterID we don't want to call the registered @freeCB function because that breaks our contract that we would only call it after succesfully returning. If the @freeCB routine were called, it could result in a double free from properly coded applications that free their opaque data on failure to register, as seen in the following details: Program terminated with signal 6, Aborted. #0 0x00007fc45cba15d7 in raise #1 0x00007fc45cba2cc8 in abort #2 0x00007fc45cbe12f7 in __libc_message #3 0x00007fc45cbe86d3 in _int_free #4 0x00007fc45d8d292c in PyDict_Fini #5 0x00007fc45d94f46a in Py_Finalize #6 0x00007fc45d960735 in Py_Main #7 0x00007fc45cb8daf5 in __libc_start_main #8 0x0000000000400721 in _start The double dereference of 'pyobj_cbData' is triggered in the following way: (1) libvirt_virConnectDomainEventRegisterAny is invoked. (2) the event is successfully added to the event callback list (virDomainEventStateRegisterClient in remoteConnectDomainEventRegisterAny returns 1 which means ok). (3) when function remoteConnectDomainEventRegisterAny is hit, network connection disconnected coincidently (or libvirtd is restarted) in the context of function 'call' then the connection is lost and the function 'call' failed, the branch virObjectEventStateDeregisterID is therefore taken. (4) 'pyobj_conn' is dereferenced the 1st time in libvirt_virConnectDomainEventFreeFunc. (5) 'pyobj_cbData' (refered to pyobj_conn) is dereferenced the 2nd time in libvirt_virConnectDomainEventRegisterAny. (6) the double free error is triggered. Resolve this by adding a @doFreeCb boolean in order to avoid calling the freeCb in virObjectEventStateDeregisterID for any remote call failure in a remoteConnect*EventRegister* API. For remoteConnect*EventDeregister* calls, the passed value would be true indicating they should run the freecb if it exists; whereas, it's false for the remote call failure path. Patch based on the investigation and initial patch posted by fangying <[email protected]>.

Direct leak of 104 byte(s) in 1 object(s) allocated from: #0 0x7f904bfbe12b (/lib64/liblsan.so.0+0xe12b) #1 0x7f904ba0ad67 in virAlloc ../../src/util/viralloc.c:144 #2 0x7f904bbc11a4 in virNetMessageNew ../../src/rpc/virnetmessage.c:42 #3 0x7f904bbb8e77 in virNetServerClientNewInternal ../../src/rpc/virnetserverclient.c:392 #4 0x7f904bbb9921 in virNetServerClientNew ../../src/rpc/virnetserverclient.c:440 #5 0x402ce5 in testIdentity ../../tests/virnetserverclienttest.c:55 #6 0x403bed in virTestRun ../../tests/testutils.c:180 #7 0x402c1e in mymain ../../tests/virnetserverclienttest.c:146 #8 0x404c80 in virTestMain ../../tests/testutils.c:1119 #9 0x4030d5 in main ../../tests/virnetserverclienttest.c:152 #10 0x7f9047f7f889 in __libc_start_main (/lib64/libc.so.6+0x20889) Indirect leak of 4 byte(s) in 1 object(s) allocated from: #0 0x7f904bfbe12b (/lib64/liblsan.so.0+0xe12b) #1 0x7f904ba0adc7 in virAllocN ../../src/util/viralloc.c:191 #2 0x7f904bbb8ec7 in virNetServerClientNewInternal ../../src/rpc/virnetserverclient.c:395 #3 0x7f904bbb9921 in virNetServerClientNew ../../src/rpc/virnetserverclient.c:440 #4 0x402ce5 in testIdentity ../../tests/virnetserverclienttest.c:55 #5 0x403bed in virTestRun ../../tests/testutils.c:180 #6 0x402c1e in mymain ../../tests/virnetserverclienttest.c:146 #7 0x404c80 in virTestMain ../../tests/testutils.c:1119 #8 0x4030d5 in main ../../tests/virnetserverclienttest.c:152 #9 0x7f9047f7f889 in __libc_start_main (/lib64/libc.so.6+0x20889) SUMMARY: LeakSanitizer: 108 byte(s) leaked in 2 allocation(s). Signed-off-by: Marc Hartmayer <[email protected]> Reviewed-by: John Ferlan <[email protected]>

The fix for CVE-2018-6764 introduced a potential deadlock scenario that gets triggered by the NSS module when virGetHostname() calls getaddrinfo to resolve the hostname: #0 0x00007f6e714b57e7 in futex_wait #1 futex_wait_simple #2 __pthread_once_slow #3 0x00007f6e71d16e7d in virOnce #4 0x00007f6e71d0997c in virLogInitialize #5 0x00007f6e71d0a09a in virLogVMessage #6 0x00007f6e71d09ffd in virLogMessage #7 0x00007f6e71d0db22 in virObjectNew #8 0x00007f6e71d0dbf1 in virObjectLockableNew #9 0x00007f6e71d0d3e5 in virMacMapNew #10 0x00007f6e71cdc50a in findLease #11 0x00007f6e71cdcc56 in _nss_libvirt_gethostbyname4_r #12 0x00007f6e724631fc in gaih_inet #13 0x00007f6e72464697 in __GI_getaddrinfo #14 0x00007f6e71d19e81 in virGetHostnameImpl #15 0x00007f6e71d1a057 in virGetHostnameQuiet #16 0x00007f6e71d09936 in virLogOnceInit #17 0x00007f6e71d09952 in virLogOnce #18 0x00007f6e714b5829 in __pthread_once_slow libvirt#19 0x00007f6e71d16e7d in virOnce libvirt#20 0x00007f6e71d0997c in virLogInitialize libvirt#21 0x00007f6e71d0a09a in virLogVMessage libvirt#22 0x00007f6e71d09ffd in virLogMessage libvirt#23 0x00007f6e71d0db22 in virObjectNew libvirt#24 0x00007f6e71d0dbf1 in virObjectLockableNew libvirt#25 0x00007f6e71d0d3e5 in virMacMapNew libvirt#26 0x00007f6e71cdc50a in findLease libvirt#27 0x00007f6e71cdc839 in _nss_libvirt_gethostbyname3_r libvirt#28 0x00007f6e71cdc724 in _nss_libvirt_gethostbyname2_r libvirt#29 0x00007f6e7248f72f in __gethostbyname2_r libvirt#30 0x00007f6e7248f494 in gethostbyname2 libvirt#31 0x000056348c30c36d in hosts_keys libvirt#32 0x000056348c30b7d2 in main Fortunately the extra stuff virGetHostname does is totally irrelevant to the needs of the logging code, so we can just inline a call to the native hostname() syscall directly. Signed-off-by: Daniel P. Berrangé <[email protected]>

Currently if the virNetServer instance is created with max_workers==0 to request a non-threaded dispatch process, we deadlock during dispatch #0 0x00007fb845f6f42d in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007fb845f681d3 in pthread_mutex_lock () from /lib64/libpthread.so.0 #2 0x000055a6628bb305 in virMutexLock (m=<optimized out>) at util/virthread.c:89 #3 0x000055a6628a984b in virObjectLock (anyobj=<optimized out>) at util/virobject.c:435 #4 0x000055a66286fcde in virNetServerClientIsAuthenticated (client=client@entry=0x55a663a7b960) at rpc/virnetserverclient.c:1565 #5 0x000055a66286cc17 in virNetServerProgramDispatchCall (msg=0x55a663a7bc50, client=0x55a663a7b960, server=0x55a663a77550, prog=0x55a663a78020) at rpc/virnetserverprogram.c:407 #6 virNetServerProgramDispatch (prog=prog@entry=0x55a663a78020, server=server@entry=0x55a663a77550, client=client@entry=0x55a663a7b960, msg=msg@entry=0x55a663a7bc50) at rpc/virnetserverprogram.c:307 #7 0x000055a662871d56 in virNetServerProcessMsg (msg=0x55a663a7bc50, prog=0x55a663a78020, client=0x55a663a7b960, srv=0x55a663a77550) at rpc/virnetserver.c:148 #8 virNetServerDispatchNewMessage (client=0x55a663a7b960, msg=0x55a663a7bc50, opaque=0x55a663a77550) at rpc/virnetserver.c:227 #9 0x000055a66286e4c0 in virNetServerClientDispatchRead (client=client@entry=0x55a663a7b960) at rpc/virnetserverclient.c:1322 #10 0x000055a66286e813 in virNetServerClientDispatchEvent (sock=<optimized out>, events=1, opaque=0x55a663a7b960) at rpc/virnetserverclient.c:1507 #11 0x000055a662899be0 in virEventPollDispatchHandles (fds=0x55a663a7bdc0, nfds=<optimized out>) at util/vireventpoll.c:508 #12 virEventPollRunOnce () at util/vireventpoll.c:657 #13 0x000055a6628982f1 in virEventRunDefaultImpl () at util/virevent.c:327 #14 0x000055a6628716d5 in virNetDaemonRun (dmn=0x55a663a771b0) at rpc/virnetdaemon.c:858 #15 0x000055a662864c1d in main (argc=<optimized out>, #argv=0x7ffd105b4838) at logging/log_daemon.c:1235 Reviewed-by: John Ferlan <[email protected]> Reviewed-by: Jim Fehlig <[email protected]> Signed-off-by: Daniel P. Berrangé <[email protected]>

On start up of libvirtd the worker pool of the QEMU driver must be initialized before trying to reconnect to all the running QEMU instances. Otherwise segmentation faults can occur if there are QEMU monitor events emitted. #0 __GI___pthread_mutex_lock #1 0x000003fffdba9e62 in virMutexLock #2 0x000003fffdbab2dc in virThreadPoolSendJob #3 0x000003ffd8343b70 in qemuProcessHandleSerialChanged #4 0x000003ffd836a776 in qemuMonitorEmitSerialChange #5 0x000003ffd8378e52 in qemuMonitorJSONHandleSerialChange #6 0x000003ffd8378930 in qemuMonitorJSONIOProcessEvent #7 0x000003ffd837edee in qemuMonitorJSONIOProcessLine #8 0x000003ffd837ef86 in qemuMonitorJSONIOProcess #9 0x000003ffd836757a in qemuMonitorIOProcess #10 0x000003ffd836863e in qemuMonitorIO #11 0x000003fffdb4033a in virEventPollDispatchHandles #12 0x000003fffdb4055e in virEventPollRunOnce #13 0x000003fffdb3e782 in virEventRunDefaultImpl #14 0x000003fffdc89400 in virNetDaemonRun #15 0x000000010002a816 in main Signed-off-by: Marc Hartmayer <[email protected]> Reviewed-by: Bjoern Walk <[email protected]> Reviewed-by: Boris Fiuczynski <[email protected]> Reviewed-by: Erik Skultety <[email protected]>

cdeadmin mentioned this issue Dec 11, 2017

virsh qemu-monitor-command does not change cpu index #7

Closed

balamuruhans mentioned this issue Mar 14, 2018

virsh qemu-attach fails to add qemu process with libvirt #14

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

PCI-Multifunction hotplug support #1

PCI-Multifunction hotplug support #1

ShivaprasadGBhat commented Sep 9, 2016

PCI-Multifunction hotplug support #1

PCI-Multifunction hotplug support #1

Comments

ShivaprasadGBhat commented Sep 9, 2016