- 10 4月, 2013 4 次提交
-
-
由 Peter Krempa 提交于
Mimic the fix done in 02b90972 to fix crash by accessing an already freed structure. Also copy the explaining comment why the pointer can't be accessed any more. (cherry picked from commit 43b6f304)
-
由 Eric Blake 提交于
Reported by Anthony Messina in https://bugzilla.redhat.com/show_bug.cgi?id=904692 Present since introduction of smartcard support in commit f5fd9baa * src/qemu/qemu_command.c (qemuBuildCommandLine): Match qemu spelling. * tests/qemuxml2argvdata/qemuxml2argv-smartcard-host-certificates.args: Fix broken test. (cherry picked from commit 6f7e4ea3)
-
由 John Ferlan 提交于
Code added by commit id '523207fe' TEST: qemuxml2argvtest ........................................ 40 ........................................ 80 ........................................ 120 ........................................ 160 ........................................ 200 ........................................ 240 ................................. 273 OK ==30993== 39 bytes in 1 blocks are definitely lost in loss record 33 of 87 ==30993== at 0x4A0887C: malloc (vg_replace_malloc.c:270) ==30993== by 0x41E501: fakeSecretGetValue (qemuxml2argvtest.c:33) ==30993== by 0x427591: qemuBuildDriveURIString (qemu_command.c:2571) ==30993== by 0x42C502: qemuBuildDriveStr (qemu_command.c:2627) ==30993== by 0x4335FC: qemuBuildCommandLine (qemu_command.c:6443) ==30993== by 0x41E8A0: testCompareXMLToArgvHelper (qemuxml2argvtest.c:154 ==30993== by 0x41FE8F: virtTestRun (testutils.c:157) ==30993== by 0x418BE3: mymain (qemuxml2argvtest.c:506) ==30993== by 0x4204CA: virtTestMain (testutils.c:719) ==30993== by 0x38D6821A04: (below main) (in /usr/lib64/libc-2.16.so) ==30993== ==30993== 46 bytes in 1 blocks are definitely lost in loss record 64 of 87 ==30993== at 0x4A0887C: malloc (vg_replace_malloc.c:270) ==30993== by 0x38D690A167: __vasprintf_chk (in /usr/lib64/libc-2.16.so) ==30993== by 0x4CB28E7: virVasprintf (stdio2.h:210) ==30993== by 0x4CB29A3: virAsprintf (virutil.c:2017) ==30993== by 0x4275B4: qemuBuildDriveURIString (qemu_command.c:2580) ==30993== by 0x42C502: qemuBuildDriveStr (qemu_command.c:2627) ==30993== by 0x4335FC: qemuBuildCommandLine (qemu_command.c:6443) ==30993== by 0x41E8A0: testCompareXMLToArgvHelper (qemuxml2argvtest.c:154 ==30993== by 0x41FE8F: virtTestRun (testutils.c:157) ==30993== by 0x418BE3: mymain (qemuxml2argvtest.c:506) ==30993== by 0x4204CA: virtTestMain (testutils.c:719) ==30993== by 0x38D6821A04: (below main) (in /usr/lib64/libc-2.16.so) ==30993== ==30993== 385 (56 direct, 329 indirect) bytes in 1 blocks are definitely los ==30993== at 0x4A06B6F: calloc (vg_replace_malloc.c:593) ==30993== by 0x4C6B2CF: virAllocN (viralloc.c:152) ==30993== by 0x4C9C7EB: virObjectNew (virobject.c:191) ==30993== by 0x4D21810: virGetSecret (datatypes.c:642) ==30993== by 0x41E5D5: fakeSecretLookupByUsage (qemuxml2argvtest.c:51) ==30993== by 0x4D4BEC5: virSecretLookupByUsage (libvirt.c:15295) ==30993== by 0x4276A9: qemuBuildDriveURIString (qemu_command.c:2565) ==30993== by 0x42C502: qemuBuildDriveStr (qemu_command.c:2627) ==30993== by 0x4335FC: qemuBuildCommandLine (qemu_command.c:6443) ==30993== by 0x41E8A0: testCompareXMLToArgvHelper (qemuxml2argvtest.c:154 ==30993== by 0x41FE8F: virtTestRun (testutils.c:157) ==30993== by 0x418BE3: mymain (qemuxml2argvtest.c:506) ==30993== PASS: qemuxml2argvtest Interesting side note is that running the test singularly via 'make -C tests check TESTS=qemuxml2argvtest' didn't trip the valgrind error; however, running during 'make -C tests valgrind' did cause the error to be seen. (cherry picked from commit 9a80050e)
-
由 Laine Stump 提交于
Commit 9a3ff01d (which was ACKed at the end of January, but for some reason didn't get pushed until during the 1.0.4 freeze) fixed the logic in virPCIGetVirtualFunctions(). Unfortunately, a typo in the fix (replacing VIR_REALLOC_N with VIR_ALLOC_N during code movement) caused not only a memory leak, but also resulted in most of the elements of the result array being replaced with NULL. virNetDevGetVirtualFunctions() assumed (and I think rightly so) that virPCIGetVirtualFunctions() wouldn't return any NULL elements in the array, so it ended up segfaulting. This was found when attempting to use a virtual network with an auto-created pool of SRIOV VFs, e.g.: <forward mode='hostdev' managed='yes'> <pf dev='eth4'/> </forward> (the pool of PCI addresses is discovered by calling virNetDevGetVirtualFunctions() on the PF dev).
-
- 29 3月, 2013 2 次提交
-
-
由 Martin Kletzander 提交于
When logical pool has no PVs associated with itself (user-created), virCommandFree(cmd) is called twice with the same pointer and that causes a segfault in daemon.
-
由 Ján Tomko 提交于
Both virIsCapableFCHost and virIsCapableVport return 0 when the respective sysfs path is accessible.
-
- 28 3月, 2013 10 次提交
-
-
由 Michal Privoznik 提交于
With my previous patches, we unconditionally appended a seclabel, even if it wasn't generated but found in array of defined seclabels. This resulted in double free later when doing virDomainDefFree and iterating over the array of defined seclabels. Moreover, there was another possibility of double free, if the seclabel was generated in the last iteration of the process of walking trough security managers array.
-
由 Michal Privoznik 提交于
There has been a typo in virIsCapbleVport function name.
-
由 Osier Yang 提交于
--- Pushed under build-breaker rule.
-
由 Michal Privoznik 提交于
One of my previous patches manipulated virSecurityLabel* APIs, some were added to header files, and some were renamed. However, these changes were not reflected in libvirt_private.syms.
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=923946 The <seclabel type='none'/> should be added iff there is no other seclabel defined within a domain. This bug can be easily reproduced: 1) configure selinux seclabel for a domain 2) disable system's selinux and restart libvirtd 3) observe <seclabel type='none'/> being appended to a domain on its startup
-
由 Michal Privoznik 提交于
The virDomainDefGetSecurityLabelDef was modifying the domain XML. It tried to find a seclabel corresponding to given sec driver. If the label wasn't found, the function created one which is wrong. In fact it's security manager which should modify this part of domain XML.
-
由 Guannan Ren 提交于
When libvirtd loads active network configs from network state directory, it should release the class_id memory block which was allocated at the time of loading xml from network config directory. virBitmapParse will create a new memory block of bitmap class_id which causes a memory leak. This happens when at least one virtual network is active before. ==12234== 8,216 (24 direct, 8,192 indirect) bytes in 1 blocks are definitely \ lost in loss record 702 of 709 ==12234== at 0x4A06B2F: calloc (vg_replace_malloc.c:593) ==12234== by 0x37AB04D77D: virAlloc (in /usr/lib64/libvirt.so.0.1000.3) ==12234== by 0x37AB04EF89: virBitmapNew (in /usr/lib64/libvirt.so.0.1000.3) ==12234== by 0x37AB0BFB37: virNetworkAssignDef (in /usr/lib64/libvirt.so.0.1000.3) ==12234== by 0x37AB0BFD31: ??? (in /usr/lib64/libvirt.so.0.1000.3) ==12234== by 0x37AB0BFE92: virNetworkLoadAllConfigs (in /usr/lib64/libvirt.so.0.1000.3) ==12234== by 0x10650E5A: ??? (in /usr/lib64/libvirt/connection-driver/libvirt_driver_network.so) ==12234== by 0x37AB0EB72F: virStateInitialize (in /usr/lib64/libvirt.so.0.1000.3) ==12234== by 0x40DE04: ??? (in /usr/sbin/libvirtd) ==12234== by 0x37AB0832E8: ??? (in /usr/lib64/libvirt.so.0.1000.3) ==12234== by 0x3796807D14: start_thread (in /usr/lib64/libpthread-2.16.so) ==12234== by 0x37960F246C: clone (in /usr/lib64/libc-2.16.so)
-
由 Guannan Ren 提交于
-
由 Guannan Ren 提交于
-
由 Stefan Seyfried 提交于
iptables-1.4.18 removed the long deprecated "state" match. Use "conntrack" instead in forwarding rules. Fixes openSUSE bug https://bugzilla.novell.com/811251 #811251.
-
- 27 3月, 2013 6 次提交
-
-
由 Viktor Mihajlovski 提交于
Check function pointer before calling. Signed-off-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
-
由 Jiri Denemark 提交于
Despite the comment stating virNetClientIncomingEvent handler should never be called with either client->haveTheBuck or client->wantClose set, there is a sequence of events that may lead to both booleans being true when virNetClientIncomingEvent is called. However, when that happens, we must not immediately close the socket as there are other threads waiting for the buck and they would cause SIGSEGV once they are woken up after the socket was closed. Another thing is we should clear all remaining calls in the queue after closing the socket. The situation that can lead to the crash involves three threads, one of them running event loop and the other two calling libvirt APIs. The event loop thread detects an event on client->sock and calls virNetClientIncomingEvent handler. But before the handler gets a chance to lock client, the other two threads (T1 and T2) start calling some APIs. T1 gets the buck and detects EOF on client->sock while processing its RPC call. Since T2 is waiting for its own call, T1 passes the buck on to it and unlocks client. But before T2 gets the signal, the event loop thread wakes up, does its job and closes client->sock. The crash happens when T2 actually wakes up and tries to do its job using a closed client->sock.
-
由 Jiri Denemark 提交于
When we write a log message into a log, we separate thread ID from timestamp using ": ". However, when storing the message into the ring buffer, we omitted the separator, e.g.: 2013-02-27 11:49:11.852+00003745: ...
-
由 Guannan Ren 提交于
#virsh detach-device $guest usb.xml error: Failed to detach device from usb2.xml error: operation failed: host usb device vendor=0x0951 \ product=0x1625 not found This regresstion is due to a typo in matching function. The first argument is always the usb device that we are checking for. If the usb xml file provided by user contains bus and device info, we try to search it by them, otherwise, we use vendor and product info. The bug occurred only when detaching a usb device with no bus and device info provided in the usb xml file.
-
由 Guido Günther 提交于
f946462e changed behavior by settings VIR_DOMAIN_DEVICE_ADDRESS_TYPE_PCI upfront. If we do so before invoking qemuDomainPCIAddressEnsureAddr we merely try to set the PCI slot via qemuDomainPCIAddressReserveSlot instead reserving a new address via qemuDomainPCIAddressSetNextAddr which fails with $ ~/run-tck-test domain/200-disk-hotplug.t ./scripts/domain/200-disk-hotplug.t .. # Creating a new transient domain ./scripts/domain/200-disk-hotplug.t .. 1/5 # Attaching the new disk /var/lib/jenkins/jobs/libvirt-tck-build/workspace/scratchdir/200-disk-hotplug/extra.img # Failed test 'disk has been attached' # at ./scripts/domain/200-disk-hotplug.t line 67. # died: Sys::Virt::Error (libvirt error code: 1, message: internal error unable to reserve PCI address 0:0:0.0 # )
-
由 Michal Privoznik 提交于
Since we switched from direct host migration scheme to the one, where we connect to the destination and then just pass a FD to a qemu, we have uncovered a qemu bug. Qemu expects migration FD to block. However, we are passing a nonblocking one which results in cryptic error messages like: qemu: warning: error while loading state section id 2 load of migration failed The bug is already known to Qemu folks, but we should workaround already released Qemus. Patch has been originally proposed by Stefan Hajnoczi <stefanha@gmail.com>
-
- 26 3月, 2013 1 次提交
-
-
由 Martin Kletzander 提交于
virConnectOpenAuth didn't require 'name' to be specified (VIR_DEBUG used NULLSTR() for the output) and by default, if name == NULL, the default connection uri is used. This was not indicated in the documentation and wasn't checked for in other API's VIR_DEBUG outputs.
-
- 25 3月, 2013 10 次提交
-
-
由 Eric Blake 提交于
This reverts commit 5ac846e4. After further discussions with Alon Levy, I learned the following: The use of '-vga qxl' vs. '-device qxl-vga' is completely orthogonal to whether ram_size can be exposed. Downstream distros are interested in backporting support for multi-head qxl, but this can be done in one of two ways: 1. Support one head per PCI device. If you do this, then it makes sense to have full control over the PCI address of each device. For full control, you need '-device qxl-vga' instead of '-vga qxl'. 2. Support multiple heads through a single PCI device. If you do this, then you need to allocate more RAM to that PCI device (enough ram to cover the multiple screens). Here, the device is hard-coded to 0:0:2.0, both in qemu and libvirt code. Apparently, backporting ram_size changes to allow multiple heads in a single device is much easier than backporting multiple device support. Furthermore, the presence or absence of qxl-vga.surfaces is no different than the presence or absence of qxl-vga.ram_size; both properties can be applied regardless of whether you have one PCI device (-vga qxl) or multiple (-device qxl-vga), so this property is NOT a good witness of whether '-device qxl-vga' support has been backported. Downstream RHEL will NOT be using this patch; and worse, leaving this patch in risks doing the wrong thing if compiling upstream libvirt on RHEL, so the best course of action is to revert it. That means that libvirt will go back to only using '-device qxl-vga' for qemu >= 1.2, but this is just fine because we know of no distros that plan on backporting multiple PCI address support to any older version of qemu. Meanwhile, downstream can still use ram_size to pack multiple heads through a single PCI device.
-
由 Osier Yang 提交于
The string written to "vport_create" or "vport_delete" should be "wwnn:wwpn", but not "wwpn:wwnn".
-
由 Osier Yang 提交于
virPCIGetVirtualFunctions returns 0 even if there is no "virtfn" entry under the device sysfs path. And virPCIGetVirtualFunctions returns -1 when it fails to get the PCI config space of one VF, however, with keeping the the VFs already detected. That's why udevProcessPCI and gather_pci_cap use logic like: if (!virPCIGetVirtualFunctions(syspath, &data->pci_dev.virtual_functions, &data->pci_dev.num_virtual_functions) || data->pci_dev.num_virtual_functions > 0) data->pci_dev.flags |= VIR_NODE_DEV_CAP_FLAG_PCI_VIRTUAL_FUNCTION; to tag the PCI device with "virtual_function" cap. However, this results in a VF will aslo get "virtual_function" cap. This patch fixes it by: * Ignoring the VF which has failure of getting PCI config space (given that the successfully detected VFs are kept , it makes sense to not give up on the failure of one VF too) with a warning, so virPCIGetVirtualFunctions will not return -1 except out of memory. * Free the allocated *virtual_functions when out of memory And thus the logic can be changed to: /* Out of memory */ int ret = virPCIGetVirtualFunctions(syspath, &data->pci_dev.virtual_functions, &data->pci_dev.num_virtual_functions); if (ret < 0 ) goto out; if (data->pci_dev.num_virtual_functions > 0) data->pci_dev.flags |= VIR_NODE_DEV_CAP_FLAG_PCI_VIRTUAL_FUNCTION;
-
由 Osier Yang 提交于
This abstracts nodeDeviceVportCreateDelete as an util function virManageVport, which can be further used by later storage patches (to support persistent vHBA, I don't want to create the vHBA using the public API, which is not good).
-
由 Osier Yang 提交于
This enrichs HBA's xml by dumping the number of max vports and vports in use. Format is like: <capability type='vport_ops'> <max_vports>164</max_vports> <vports>5</vports> </capability> * docs/formatnode.html.in: (Document the new XML) * docs/schemas/nodedev.rng: (Add the schema) * src/conf/node_device_conf.h: (New member for data.scsi_host) * src/node_device/node_device_linux_sysfs.c: (Collect the value of max_vports and vports)
-
由 Osier Yang 提交于
This adds two util functions (virIsCapableFCHost and virIsCapableVport), and rename helper check_fc_host_linux as detect_scsi_host_caps, check_capable_vport_linux is removed, as it's abstracted to the util function virIsCapableVport. detect_scsi_host_caps nows detect both the fc_host and vport_ops capabilities. "stat(2)" is replaced with "access(2)" for saving. * src/util/virutil.h: - Declare virIsCapableFCHost and virIsCapableVport * src/util/virutil.c: - Implement virIsCapableFCHost and virIsCapableVport * src/node_device/node_device_linux_sysfs.c: - Remove check_capable_vport_linux - Rename check_fc_host_linux as detect_scsi_host_caps, and refactor it a bit to detect both fc_host and vport_os capabilities * src/node_device/node_device_driver.h: - Change/remove the related declarations * src/node_device/node_device_udev.c: (Use detect_scsi_host_caps) * src/node_device/node_device_hal.c: (Likewise) * src/node_device/node_device_driver.c (Likewise)
-
由 Osier Yang 提交于
The use of 'stat' in nodeDeviceVportCreateDelete is only to check if the file exists or not, it's a bit overkill, and safe to replace with the wrapper of access(2) (virFileExists).
-
由 Osier Yang 提交于
"open_wwn_file" in node_device_linux_sysfs.c is redundant, on one hand it duplicates work of virFileReadAll, on the other hand, it's waste to use a function for it, as there is no other users of it. So I don't see why the file opening work cannot be done in "read_wwn_linux". "read_wwn_linux" can be abstracted as an util function. As what all it does is to read the sysfs entry. So this patch removes "open_wwn_file", and abstract "read_wwn_linux" as an util function "virReadFCHost" (a more general name, because after changes, it can read each of the fc_host entry now). * src/util/virutil.h: (Declare virReadFCHost) * src/util/virutil.c: (Implement virReadFCHost) * src/node_device/node_device_linux_sysfs.c: (Remove open_wwn_file, and read_wwn_linux) src/node_device/node_device_driver.h: (Remove the declaration of read_wwn_linux, and the related macros) src/libvirt_private.syms: (Export virReadFCHost)
-
由 Osier Yang 提交于
VIR_CONNECT_LIST_NODE_DEVICES_CAP_FC_HOST to filter the FC HBA, and VIR_CONNECT_LIST_NODE_DEVICES_CAP_VPORTS to filter the FC HBA which supports vport.
-
由 Osier Yang 提交于
Guess it was created for the fc_host and vports_ops capabilities purpose, but there is enum virNodeDevScsiHostCapFlags for them, and enum virNodeDevHBACapType is unused, and actually both VIR_ENUM_DECL and VIR_ENUM_IMPL use the wrong enum name "virNodeDevHBACap".
-
- 23 3月, 2013 6 次提交
-
-
由 Martin Kletzander 提交于
When the container has the same '/dev' mount as host (no chroot), calling domainShutdown(WithFlags) shouldn't shutdown the host it is running on.
-
由 Daniel P. Berrange 提交于
For a root filesystem with type=file or type=block, the LXC container was forgetting to actually mount it, before doing the pivot root step. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Currently the lxc controller sets up the devpts instance on $rootfsdef->src, but this only works if $rootfsdef is using type=mount. To support type=block or type=file for the root filesystem, we must use /var/lib/libvirt/lxc/$NAME.devpts for the temporary devpts mount in the controller
-
由 Daniel P. Berrange 提交于
Instead of using /var/lib/libvirt/lxc/$NAME for the FUSE filesystem, use /var/lib/libvirt/lxc/$NAME.fuse. This allows room for other temporary mounts in the same directory
-
由 Daniel P. Berrange 提交于
Some of the LXC callbacks did not lock the virDomainObjPtr instance. This caused transient errors like error: Failed to start domain busy-mount error: cannot rename file '/var/run/libvirt/lxc/busy-mount.xml.new' as '/var/run/libvirt/lxc/busy-mount.xml': No such file or directory as 2 threads tried to update the status file concurrently Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
The virDomainGetRootFilesystem was only returning filesystems with type=mount. This is bogus - any type of filesystem is valid as the root, if dst=/. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 22 3月, 2013 1 次提交
-
-
由 Jim Fehlig 提交于
Noticed that parsing bond interface XML containing the miimon element fails <interface type="bond" name="bond0"> ... <bond mode="active-backup"> <miimon freq="100" carrier="netif"/> ... </bond> </interface> This configuration does not contain the optional updelay and downdelay attributes, but parsing will fail due to returning the result of virXPathULong (a -1 when the attribute doesn't exist) from virInterfaceDefParseBond after examining the updelay attribute. While fixing this bug, cleanup the function to use virXPathInt instead of virXPathULong, and store the result directly instead of using a tmp variable. Using virXPathInt actually fixes a potential silent truncation bug noted by Eric Blake. Also, there is no cleanup in the error label. Remove the label, returning failure where failure occurs and success if the end of the function is reached.
-