- 11 5月, 2017 31 次提交
-
-
由 Pavel Hrdina 提交于
Found by running valgrind for these tests. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> (cherry picked from commit 9005a64b)
-
由 Pavel Hrdina 提交于
Commit 252610f7 switched to use hash to store servers. Function virHashGetItems returns allocated array which needs to be freed also for successful path, not only if there is an error. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> (cherry picked from commit ab0a461b)
-
由 Pavel Hrdina 提交于
All of the variables are filled inside a loop and therefore needs to be also freed in every cycle. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> (cherry picked from commit ffc810b7)
-
由 Pavel Hrdina 提交于
Commit 14319c81 introduced CPU host model in domain capabilities and the *hostmodel* variable is always filled by virCPUDefCopy() and needs to be freed. Signed-off-by: NPavel Hrdina <phrdina@redhat.com> (cherry picked from commit 87d97a9d)
-
由 Marc Hartmayer 提交于
There were multiple race conditions that could lead to segmentation faults. The first precondition for this is qemuProcessLaunch must fail sometime shortly after starting the new QEMU process. The second precondition for the segmentation faults is that the new QEMU process dies - or to be more precise the QEMU monitor has to be closed irregularly. If both happens during qemuProcessStart (starting a domain) there are race windows between the thread with the event loop (T1) and the thread that is starting the domain (T2). First segmentation fault scenario: If qemuProcessLaunch fails during qemuProcessStart the code branches to the 'stop' path where 'qemuMonitorSetDomainLog(priv->mon, NULL, NULL, NULL)' will set the log function of the monitor to NULL (done in T2). In the meantime the event loop of T1 will wake up with an EOF event for the QEMU monitor because the QEMU process has died. The crash occurs if T1 has checked 'mon->logFunc != NULL' in qemuMonitorIO just before the logFunc was set to NULL by T2. If this situation occurs T1 will try to call mon->logFunc which leads to the segmentation fault. Solution: Require the monitor lock for setting the log function. Backtrace: 0 0x0000000000000000 in ?? () 1 0x000003ffe9e45316 in qemuMonitorIO (watch=<optimized out>, fd=<optimized out>, events=<optimized out>, opaque=0x3ffe08aa860) at ../../src/qemu/qemu_monitor.c:727 2 0x000003fffda2e1a4 in virEventPollDispatchHandles (nfds=<optimized out>, fds=0x2aa000fd980) at ../../src/util/vireventpoll.c:508 3 0x000003fffda2e398 in virEventPollRunOnce () at ../../src/util/vireventpoll.c:657 4 0x000003fffda2ca10 in virEventRunDefaultImpl () at ../../src/util/virevent.c:314 5 0x000003fffdba9366 in virNetDaemonRun (dmn=0x2aa000cc550) at ../../src/rpc/virnetdaemon.c:818 6 0x000002aa00024668 in main (argc=<optimized out>, argv=<optimized out>) at ../../daemon/libvirtd.c:1541 Second segmentation fault scenario: If qemuProcessLaunch fails it will unref the log context and with invoking qemuMonitorSetDomainLog(priv->mon, NULL, NULL, NULL) qemuDomainLogContextFree() will be invoked. qemuDomainLogContextFree() invokes virNetClientClose() to close the client and cleans everything up (including unref of _virLogManager.client) when virNetClientClose() returns. When T1 is now trying to report 'qemu unexpectedly closed the monitor' libvirtd will crash because the client has already been freed. Solution: As the critical section in qemuMonitorIO is protected with the monitor lock we can use the same solution as proposed for the first segmentation fault. Backtrace: 0 virClassIsDerivedFrom (klass=0x3100979797979797, parent=0x2aa000d92f0) at ../../src/util/virobject.c:169 1 0x000003fffda659e6 in virObjectIsClass (anyobj=<optimized out>, klass=<optimized out>) at ../../src/util/virobject.c:365 2 0x000003fffda65a24 in virObjectLock (anyobj=0x3ffe08c1db0) at ../../src/util/virobject.c:317 3 0x000003fffdba4688 in virNetClientIOEventLoop (client=client@entry=0x3ffe08c1db0, thiscall=thiscall@entry=0x2aa000fbfa0) at ../../src/rpc/virnetclient.c:1668 4 0x000003fffdba4b4c in virNetClientIO (client=client@entry=0x3ffe08c1db0, thiscall=0x2aa000fbfa0) at ../../src/rpc/virnetclient.c:1944 5 0x000003fffdba4d42 in virNetClientSendInternal (client=client@entry=0x3ffe08c1db0, msg=msg@entry=0x2aa000cc710, expectReply=expectReply@entry=true, nonBlock=nonBlock@entry=false) at ../../src/rpc/virnetclient.c:2116 6 0x000003fffdba6268 in virNetClientSendWithReply (client=0x3ffe08c1db0, msg=0x2aa000cc710) at ../../src/rpc/virnetclient.c:2144 7 0x000003fffdba6e8e in virNetClientProgramCall (prog=0x3ffe08c1120, client=<optimized out>, serial=<optimized out>, proc=<optimized out>, noutfds=<optimized out>, outfds=0x0, ninfds=0x0, infds=0x0, args_filter=0x3fffdb64440 <xdr_virLogManagerProtocolDomainReadLogFileArgs>, args=0x3ffffffe010, ret_filter=0x3fffdb644c0 <xdr_virLogManagerProtocolDomainReadLogFileRet>, ret=0x3ffffffe008) at ../../src/rpc/virnetclientprogram.c:329 8 0x000003fffdb64042 in virLogManagerDomainReadLogFile (mgr=<optimized out>, path=<optimized out>, inode=<optimized out>, offset=<optimized out>, maxlen=<optimized out>, flags=0) at ../../src/logging/log_manager.c:272 9 0x000003ffe9e0315c in qemuDomainLogContextRead (ctxt=0x3ffe08c2980, msg=0x3ffffffe1c0) at ../../src/qemu/qemu_domain.c:4422 10 0x000003ffe9e280a8 in qemuProcessReadLog (logCtxt=<optimized out>, msg=msg@entry=0x3ffffffe288) at ../../src/qemu/qemu_process.c:1800 11 0x000003ffe9e28206 in qemuProcessReportLogError (logCtxt=<optimized out>, msgprefix=0x3ffe9ec276a "qemu unexpectedly closed the monitor") at ../../src/qemu/qemu_process.c:1836 12 0x000003ffe9e28306 in qemuProcessMonitorReportLogError (mon=mon@entry=0x3ffe085cf10, msg=<optimized out>, opaque=<optimized out>) at ../../src/qemu/qemu_process.c:1856 13 0x000003ffe9e452b6 in qemuMonitorIO (watch=<optimized out>, fd=<optimized out>, events=<optimized out>, opaque=0x3ffe085cf10) at ../../src/qemu/qemu_monitor.c:726 14 0x000003fffda2e1a4 in virEventPollDispatchHandles (nfds=<optimized out>, fds=0x2aa000fd980) at ../../src/util/vireventpoll.c:508 15 0x000003fffda2e398 in virEventPollRunOnce () at ../../src/util/vireventpoll.c:657 16 0x000003fffda2ca10 in virEventRunDefaultImpl () at ../../src/util/virevent.c:314 17 0x000003fffdba9366 in virNetDaemonRun (dmn=0x2aa000cc550) at ../../src/rpc/virnetdaemon.c:818 18 0x000002aa00024668 in main (argc=<optimized out>, argv=<optimized out>) at ../../daemon/libvirtd.c:1541 Other code parts where the same problem was possible to occur are fixed as well (qemuMigrationFinish, qemuProcessStart, and qemuDomainSaveImageStartVM). Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com> Reported-by: NSascha Silbe <silbe@linux.vnet.ibm.com> (cherry picked from commit 20e95cb7)
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1439132 Add "bsd" to the list of format types to not checked during blkid processing even though it supposedly knows the format - for some (now unknown) reason it's returning partition table not found. So let's just let PARTED handle "bsd" too. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> (cherry picked from commit 98f424d5)
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1439132 Commit id 'a48c674f' added a check for format types "dvh" and "pc98" to use the parted print processing instead of using blkid processing in order to validate the label on the disk was what is expected for disk pool startup. However, commit id 'a4cb4a74' really messed things up by missing an else condition causing PARTEDFindLabel to always return DIFFERENT. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> (cherry picked from commit f2a12320)
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com> (cherry picked from commit be193c4d)
-
由 Pavel Hrdina 提交于
Signed-off-by: NPavel Hrdina <phrdina@redhat.com> (cherry picked from commit d58c146a)
-
由 Jiri Denemark 提交于
There is no async job running when a freshly started libvirtd is trying to recover from an interrupted incoming migration. While at it, let's call qemuMigrationResetTLS every time we don't kill the domain. This is not strictly necessary since TLS is not supported when v2 migration protocol is used, but doing so makes more sense. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> (cherry picked from commit 59b28eca)
-
由 Jiri Denemark 提交于
We want to ignore all files except *.pl in build-aux directory, however the unignore pattern "!/build-aux/*.pl" doesn't have any effect because a previous "/build-aux/" pattern ignores the directory itself rather than individual files in it. https://bugzilla.redhat.com/show_bug.cgi?id=1439994Signed-off-by: NJiri Denemark <jdenemar@redhat.com> (cherry picked from commit f0ad8e7e)
-
由 Martin Kletzander 提交于
If formatting NUMA topology fails, the function returns immediatelly, but the buffer structure allocated on the stack references lot of heap-allocated memory and that would get lost in such case. Signed-off-by: NMartin Kletzander <mkletzan@redhat.com> (cherry picked from commit 6369ee04)
-
由 Michal Privoznik 提交于
This function runs an iscsi command and parses its output. However, due to the nature of things, virISCSIExtractSession() callback can be called multiple times. In each run it would allocate new memory and overwrite the variable where we keep pointer to it and thus leaking old allocations. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit 9c037c6c)
-
由 Michal Privoznik 提交于
Imagine that this function is called twice over the same disk source. While in the first run all allocated memory is freed, not all pointers are set to NULL (e.g. def->srcpool). So when called again, these poitners are freed again resulting in double free. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com> (cherry picked from commit 349badbf)
-
由 Jiri Denemark 提交于
Jumping to "endjob" label from a code after this label is not a very good idea. Signed-off-by: NJiri Denemark <jdenemar@redhat.com> (cherry picked from commit d658c859)
-
由 Peter Krempa 提交于
After restart of libvirtd the 'checkPool' method is supposed to validate that the pool is online. Since libvirt then refreshes the pool contents anyways just return whether the pool was supposed to be online so that the code can be reached. This is necessary since if a pool does not implement the method it's automatically considered as inactive. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1436065 (cherry picked from commit a200ebbc)
-
由 Peter Krempa 提交于
qemu requires that the topology equals to the maximum vcpu count. Document this along with the API to set maximum vcpu count and the XML element. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1426220 (cherry picked from commit 4661a186)
-
由 John Ferlan 提交于
On any failure, call virJSONValueFree for the *Props. Signed-off-by: NJohn Ferlan <jferlan@redhat.com> (cherry picked from commit 2e8c6095)
-
由 John Ferlan 提交于
Initialize stack variable to {0} Signed-off-by: NJohn Ferlan <jferlan@redhat.com> (cherry picked from commit 83c58ea3)
-
由 Peter Krempa 提交于
The native gluster pool source list data differs from the data used for attaching gluster volumes as netfs pools. Currently the only difference was the format. Since native pools don't use it and later there will be more differences add a more deterministic way to switch between the types instead. (cherry picked from commit a92160db)
-
由 Ján Tomko 提交于
Similar to commit b202c39a ignore the warning that breaks the build with clang: util/virnetlink.c:365:52: error: cast from 'char *' to 'struct nlmsghdr *' increases required alignment from 1 to 4 [-Werror,-Wcast-align] for (msg = resp; NLMSG_OK(msg, len); msg = NLMSG_NEXT(msg, len)) { ^~~~~~~~~~~~~~~~~~~~ /usr/include/linux/netlink.h:87:7: note: expanded from macro 'NLMSG_NEXT' (struct nlmsghdr*)(((char*)(nlh)) + NLMSG_ALIGN((nlh)->nlmsg_len))) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (cherry picked from commit 04be4111)
-
由 Peter Krempa 提交于
Vcpu order is required to stay sequential. Clear the order on cpu coldplug to avoid issues with removing vcpus out of sequence. (cherry picked from commit b416a33a)
-
由 Peter Krempa 提交于
'next' is declared as 'ssize_t' so use '%zd' (cherry picked from commit 86d69c30)
-
由 Peter Krempa 提交于
Buggy condition meant that vcpu0 would not be iterated in the checks. Since it's not hotpluggable anyways we would not be able to break the configuration of a live VM. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1437013 (cherry picked from commit 315f443d)
-
由 Erik Skultety 提交于
Like all devices, add the 'id' option for mdevs as well. Patch also adjusts the test accordingly. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1438431Signed-off-by: NErik Skultety <eskultet@redhat.com> (cherry picked from commit c3272e5e)
-
由 John Ferlan 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1371892 The 'capacity' value (e.g. guest logical size) for a LUKS volume is smaller than the 'physical' value of the file in the file system, so we need to account for that. When peeking at the encryption information about the volume add a fetch of the payload_offset which is described as the offset to the start of the volume data (in 512 byte sectors) in QEMU's QCryptoBlockLUKSHeader. Then adjust the ->capacity appropriately when we determine that the volume target encryption has a payload_offset value. (cherry picked from commit b7d44f45)
-
由 Cédric Bosdonnat 提交于
Add check for more than one RTA_OIF, even though this is rather unlikely. Get rid of the buggy switch / break as this code won't need to handle more attributes. Use VIR_WARNINGS_NO_CAST_ALIGN to fix impossible to fix util/virnetdevip.c:560:17: error: cast increases required alignment of target type [-Werror=cast-align] (cherry picked from commit b202c39a)
-
由 Peter Krempa 提交于
If a transient storage pool is deemed inactive after libvirtd restart it would not be deleted from the list. Reuse virStoragePoolUpdateInactive along with a refactor necessary to properly update the state. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1242801 (cherry picked from commit f3a8e80c)
-
由 Peter Krempa 提交于
After a pool is made inactive the definition objects need to be updated (if a new definition is prepared) and transient pools need to be completely removed. Split out the code doing these steps into a separate function for later reuse. (cherry picked from commit aced6b23)
-
由 Peter Krempa 提交于
When registering a storage poll backend, the code would use virStorageTypeToString instead of virStoragePoolTypeToString. The following message would be logged: virDriverLoadModuleFunc:71 : Lookup function 'virStorageBackendSCSIRegister' virStorageBackendRegister:174 : Registering storage backend '(null)' (cherry picked from commit 894133a3)
-
- 04 5月, 2017 2 次提交
-
-
由 Erik Skultety 提交于
The problem resides in virHostdevUpdateActiveMediatedDevices which gets called during qemuProcessReconnect. The issue here is that virMediatedDeviceListAdd takes a pointer to the item to be added to the list to which VIR_APPEND_ELEMENT is used, which also clears the pointer. However, in this case only the local copy of the pointer got cleared, leaving the original pointing to valid memory. To sum it up, during cleanup phase, the original pointer is freed and the daemon crashes basically any time it would access it. Backtrace: 0x00007ffff3ccdeba in __strcmp_sse2_unaligned 0x00007ffff72a444a in virMediatedDeviceListFindIndex 0x00007ffff7241446 in virHostdevReAttachMediatedDevices 0x00007fffc60215d9 in qemuHostdevReAttachMediatedDevices 0x00007fffc60216dc in qemuHostdevReAttachDomainDevices 0x00007fffc6046e6f in qemuProcessStop 0x00007fffc6091596 in processMonitorEOFEvent 0x00007fffc6091793 in qemuProcessEventHandler 0x00007ffff7294bf5 in virThreadPoolWorker 0x00007ffff7294184 in virThreadHelper 0x00007ffff3fdc3c4 in start_thread () from /lib64/libpthread.so.0 0x00007ffff3d269cf in clone () from /lib64/libc.so.6 Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1446455 (cherry picked from commit 92e30a4d) Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
由 Erik Skultety 提交于
Use a local variable to hold data, rather than accessing the pointer after calling virMediatedDeviceListAdd (therefore VIR_APPEND_ELEMENT). Although not causing an issue at the moment, this change is a necessary prerequisite for tweaking virMediatedDeviceListAdd in a separate patch, which will take a reference for the source pointer (instead of pointer value) and will clear it along the way. (cherry picked from commit 2739a983) Signed-off-by: NErik Skultety <eskultet@redhat.com>
-
- 06 4月, 2017 1 次提交
-
-
由 Jiri Denemark 提交于
qemuProcessVerifyHypervFeatures is supposed to check whether all requested hyperv features were actually honored by QEMU/KVM. This is done by checking the corresponding CPUID bits reported by the virtual CPU. In other words, it doesn't work for string properties, such as VIR_DOMAIN_HYPERV_VENDOR_ID (there is no CPUID bit we could check). We could theoretically check all 96 bits corresponding to the vendor string, but luckily we don't have to check the feature at all. If QEMU is too old to support hyperv features, the domain won't even start. Otherwise, it is always supported. Without this patch, libvirt refuses to start a domain which contains <features> <hyperv> <vendor_id state='on' value='...'/> </hyperv> </features> reporting internal error: "unknown CPU feature __kvm_hv_vendor_id. This regression was introduced by commit v3.1.0-186-ge9dbe701, which (by fixing the virCPUDataCheckFeature condition in qemuProcessVerifyHypervFeatures) revealed an old bug in the feature verification code. It's been there ever since the verification was implemented by commit v1.3.3-rc1-5-g95bbe4bf, which effectively did not check VIR_DOMAIN_HYPERV_VENDOR_ID at all. https://bugzilla.redhat.com/show_bug.cgi?id=1439424Signed-off-by: NJiri Denemark <jdenemar@redhat.com> (cherry picked from commit ae102b5d)
-
- 04 4月, 2017 1 次提交
-
-
由 Nikolay Shirokovskiy 提交于
(cherry picked from commit 609cc5a8) Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 02 4月, 2017 1 次提交
-
-
由 Daniel Veillard 提交于
* docs/news.xml: update for release * po/*.po*: regenerated
-
- 01 4月, 2017 3 次提交
-
-
由 Roman Bogorodskiy 提交于
USB tables -> USB tablet.
-
由 Dawid Zamirski 提交于
that is: s/hyperyVerifyResponse/hypervVerifyResponse/
-
由 Jiri Denemark 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1389313Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
- 31 3月, 2017 1 次提交
-
-
由 Erik Skultety 提交于
There was an unhandled 'open' call which resulted in: "error: Library function returned error but did not set virError" Even if this happens during the daemon's start when we still don't have any set of outputs defined yet, we can safely report an error, since we automatically fallback to stderr which is fine even for both running as a daemonized process, since this happens before the daemon forks into the background, and running as a systemd service, since systemd re-directs std outputs to journald by default. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1436060Signed-off-by: NErik Skultety <eskultet@redhat.com>
-