- 09 1月, 2014 9 次提交
-
-
由 Eric Blake 提交于
For storage volume validation, we weren't consistent on whether to use VIR_FROM_NONE or VIR_FROM_STORAGE. Similar to previous patches, use a common macro to make it nicer. Furthermore, just as in commit 6e130ddc, the difference between VIR_IS_STORAGE_VOL and VIR_IS_CONNECTED_STORAGE_VOL is moot (due to reference counting, any valid volume must be tied to a valid connection). virStorageVolCreateXMLFrom allows cross-connection cloning, where the error is reported against the connection of the destination pool. * src/datatypes.h (virCheckStorageVolReturn) (virCheckStorageVolGoto): New macros. (VIR_IS_STORAGE_VOL, VIR_IS_CONNECTED_STORAGE_VOL): Drop unused macros. * src/libvirt.c: Use macro throughout. (virLibStorageVolError): Drop unused macro. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Guido Günther 提交于
We point to the manpages where available and redirect to libvirt's homepage as a last resort.
-
由 Stefan Bader 提交于
This basically reverts commit ba64b971 "libxl: Allow libxl to set NIC devid". However assigning devid's before calling libxlMakeNic does not work as that is calling libxl_device_nic_init which sets it back to -1. Right now auto-assignment only works in the hotplug case. But even if that would be fixed at some point (if that is possible at all), this would add a weird dependency between Xen and libvirt versions. The change here should accept any auto-assignment that makes it into libxl_device_nic_init. My understanding is that a caller always is allowed to make the devid choice itself. And assuming libxlMakeNicList is only used on domain creation, a sequential numbering should be ok. Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
-
由 Eric Blake 提交于
virStoragePoolBuild reported an invalid pool as if it were an invalid network. Likewise, we weren't consistent on whether to use VIR_FROM_NONE or VIR_FROM_STORAGE. Similar to previous patches, use a common macro to make it nicer. Furthermore, just as in commit 6e130ddc, the difference between VIR_IS_STORAGE_POOL and VIR_IS_CONNECTED_STORAGE_POOL is moot (due to reference counting, any valid pool must be tied to a valid connection). For now, we don't need virCheckStoragePoolGoto(). * src/datatypes.h (virCheckStoragePoolReturn): New macro. (VIR_IS_STORAGE_POOL, VIR_IS_CONNECTED_STORAGE_POOL): Drop unused macros. * src/libvirt.c: Use macro throughout. (virLibStoragePoolError): Drop unused macro. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Richard W.M. Jones 提交于
There is no easy way to test authentication against libvirt. This commit modifies the test driver to allow simple username/password authentication. You modify the test XML by adding: <node> ... <auth> <user password="123456">rich</user> <user>jane</user> </auth> </node> If there are any /node/auth/user elements, then authentication is required by the test driver (if none are present, then the test driver will work as before and not require authentication). In the example above, two phony users are added: rich password: 123456 jane no password required The test driver will demand a username. If the password attribute is present (or if the username entered is wrong), then the password is also asked for and checked: $ virsh -c test://$(pwd)/testnode.xml list Enter username for localhost: rich Enter rich's password for localhost: *** Id Name State ---------------------------------------------------- 1 fv0 running 2 fc4 running Signed-off-by: NRichard W.M. Jones <rjones@redhat.com>
-
由 Eric Blake 提交于
When checking for a valid interface, we weren't consistent on whether we reported as VIR_FROM_NONE or VIR_FROM_INTERFACE. Similar to previous patches, use a common macro to make it nicer. Furthermore, just as in commit 6e130ddc, the difference between VIR_IS_INTERFACE and VIR_IS_CONNECTED_INTERFACE is moot (due to reference counting, any valid interface must be tied to a valid connection). For now, we don't need virCheckInterfaceGoto(). * src/datatypes.h (virCheckInterfaceReturn): New macro. (VIR_IS_INTERFACE, VIR_IS_CONNECTED_INTERFACE): Drop unused macros. * src/libvirt.c: Use macro throughout. (virLibInterfaceError): Drop unused macro. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
Commit cfd62c1f was incomplete; I found more cases where error messages were being overwritten, and where the code between the three registration/deregistration APIs was not consistent. Since it is fairly easy to trigger an attempt to deregister an unregistered object through public API, I also changed the error message from VIR_ERR_INTERNAL_ERROR to VIR_ERR_INVALID_ARG. * src/conf/object_event.c (virObjectEventCallbackListEventID): Inline... (virObjectEventStateEventID): ...into lone caller, and report error on failure. (virObjectEventCallbackListAddID, virObjectEventStateCallbackID) (virObjectEventCallbackListRemoveID) (virObjectEventCallbackListMarkDeleteID): Tweak error category. * src/remote/remote_driver.c (remoteConnectDomainEventRegister): Don't leak registration on failure. (remoteConnectDomainEventDeregisterAny) (remoteConnectNetworkEventDeregisterAny): Don't overwrite error. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Guido Günther 提交于
-
由 Eric Blake 提交于
When checking for a valid network, we weren't consistent on whether we reported an invalid network or a connection. Similar to previous patches such as commit 6e130ddc, the difference between VIR_IS_NETWORK and VIR_IS_CONNECTED_NETWORK is moot (due to reference counting, any valid network must be tied to a valid connection). Use a common macro to make the error reporting for invalid networks nicer. * src/datatypes.h (virCheckNetworkReturn, virCheckNetworkGoto): New macros. (VIR_IS_NETWORK, VIR_IS_CONNECTED_NETWORK): Drop unused macros. * src/libvirt.c: Use macro throughout. (virLibNetworkError): Drop unused macro. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 08 1月, 2014 19 次提交
-
-
由 Osier Yang 提交于
Like commit 94a26c7e from Eric Blake, the old fuzzy code should be replaced by the new array management macros now. And the type of scsi->count should be changed into "size_t", and thus virSCSIDeviceListCount should return size_t instead, similar for vir{PCI,USB}DeviceListCount.
-
由 Chen Hanxiao 提交于
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>
-
由 Gao feng 提交于
the unix socket /var/run/libvirt/lxc/domain.sock is not created under the selinux context which configured by <seclabel>. If we try to connect the domain.sock under the selinux context of domain in virtLXCProcessConnectMonitor,selinux will deny this connect operation. type=AVC msg=audit(1387953696.067:662): avc: denied { connectto } for pid=21206 comm="libvirtd" path="/usr/local/var/run/libvirt/lxc/systemd.sock" scontext=unconfined_u:system_r:svirt_lxc_net_t:s0:c770,c848 tcontext=unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket fix this problem by creating socket under selinux context of domain. Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
由 Peter Krempa 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1049529 The 'detach-disk' command in virsh used the active XML definition of a domain even when attempting to remove a disk from the config only. If the disk was only in the inactive definition the operation failed. Fix this by using the inactive XML in case that only the config is affected.
-
由 Peter Krempa 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=1049529 The legacy virDomainAttachDevice and virDomainDetachDevice operate only on active domains. When a user specified --current flag with an inactive domain the old API was used and reported an error. Fix it by calling the new API if --current is specified explicitly.
-
由 Michal Privoznik 提交于
The function checks for @conn to be valid and locks its mutex. Then, it checks if callee is unregistering the same callback that he registered previously. If this fails an error is reported and the control jumps to 'error' label. Here, if @conn has some errors (and it certainly does - the one that's been just reported) the conn->mutex is locked again - without any previous unlock: Thread 1 (Thread 0x7fb500ef1800 (LWP 18982)): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x00007fb4fd99ce56 in _L_lock_918 () from /lib64/libpthread.so.0 #2 0x00007fb4fd99ccaa in __GI___pthread_mutex_lock (mutex=0x7fb50153b670) at pthread_mutex_lock.c:64 #3 0x00007fb5007e574d in virMutexLock (m=m@entry=0x7fb50153b670) at util/virthreadpthread.c:85 #4 0x00007fb5007b198e in virDispatchError (conn=conn@entry=0x7fb50153b5e0) at util/virerror.c:594 #5 0x00007fb5008a3735 in virConnectUnregisterCloseCallback (conn=0x7fb50153b5e0, cb=cb@entry=0x7fb500f588e0 <vshCatchDisconnect>) at libvirt.c:21025 #6 0x00007fb500f5d690 in vshReconnect (ctl=ctl@entry=0x7fffff60e710) at virsh.c:328 #7 0x00007fb500f5dc50 in vshCommandRun (ctl=ctl@entry=0x7fffff60e710, cmd=0x7fb50152ca80) at virsh.c:1755 #8 0x00007fb500f5861b in main (argc=<optimized out>, argv=<optimized out>) at virsh.c:3393 And since the conn's mutex is not recursive, the virDispatchError will never ever lock it successfully. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Eric Blake 提交于
Cleanup after a previous patch, commit 6e130ddc. In particular, note that xenDomainUsedCpus can only be reached from xenUnifiedDomainGetXMLDesc, which in turn is only reached from public API that already validated the domain. * src/xen/xen_driver.c (xenDomainUsedCpus): Drop redundant check. * src/datatypes.h (VIR_IS_DOMAIN, VIR_IS_CONNECTED_DOMAIN): Delete, and inline into all callers, since no other file uses it any more. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Guido Günther 提交于
Make it easy to install the shipped examples. The aim is to have reasonably working templates so that distros only need to minimally patch these and can feed things upstream more easily. This was prompted by http://bugs.debian.org/725144
-
由 Eric Blake 提交于
In datatype.c, virGetDomainSnapshot could result in the message: error: invalid domain pointer in bad domain Furthermore, while there are a few functions in libvirt.c that only care about a virDomainPtr without regards to the connection (such as virDomainGetName), most functions also require a valid connection. Yet several functions were blindly dereferencing the conn member without checking it for validity first (such as virDomainOpenConsole). Rather than try and correct all usage of VIR_IS_DOMAIN vs. VIR_IS_CONNECTED_DOMAIN, it is easier to just blindly require that a valid domain object always has a valid connection object (which should be true anyways, since every domain object holds a reference to its connection, so the connection will not be closed until all domain objects have also been closed to release their reference). After this patch, all places that validate a domain consistently report: error: invalid domain pointer in someFunc * src/datatypes.h (virCheckDomainReturn, virCheckDomainGoto): New macros. * src/datatypes.c (virGetDomainSnapshot): Use new macro. (virLibConnError): Delete unused macro. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
While comparing network and domain events, I noticed that the test driver had to do a cast in one place and not the other. For consistency, we should hide the necessary casting as low as possible in the stack, with everything else using saner types. * src/conf/network_event.h (virNetworkEventStateRegisterID): Alter type. * src/conf/network_event.c (virNetworkEventStateRegisterID): Hoist cast here. * src/test/test_driver.c (testConnectNetworkEventRegisterAny): Simplify callers. * src/remote/remote_driver.c (remoteConnectNetworkEventRegisterAny): Likewise. * src/network/bridge_driver.c (networkConnectNetworkEventRegisterAny): Likewise. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
If a user registers for a domain event filtered to a particular domain, but the persistent domain is offline at the time, then the code silently failed to set up the filter. As a result, the event fires for all domains, rather than being filtered. Network events were immune, since they always passed an id 0 argument. The key to this patch is realizing that virObjectEventDispatchMatchCallback() only cared about uuid; so refusing to create a meta for a negative id is pointless, and in fact, malloc'ing meta at all was overkill; instead, just directly store a uuid and a flag of whether to filter. Note that virObjectEventPtr still needs all fields of meta, because this is how we reconstruct a virDomainPtr inside the dispatch handler before calling the end user's callback pointer with the correct object, even though only the uuid portion of meta is used in deciding whether a callback matches the given event. So while uuid is optional for callbacks, it is mandatory for events. The change to testDomainCreateXMLMixed is merely on the setup scenario (as you can't register for a domain unless it is either running or persistent). I actually first wrote that test for this patch, then rebased it to also cover a prior patch (commit 4221d64f), but had to adjust it for that patch to use Create instead of Define for setting up the domain long enough to register the event in order to work around this bug. But while the setup is changed, the main body of the test is still about whether creation events fire as expected. * src/conf/object_event_private.h (_virObjectEventCallback): Replace meta with uuid and flag. (virObjectEventCallbackListAddID): Update signature. * src/conf/object_event.h (virObjectEventStateRegisterID): Likewise. * src/conf/object_event_private.h (virObjectEventNew): Document use of name and uuid in events. * src/conf/object_event.c (virObjectEventCallbackListAddID): Drop arguments that don't affect filtering. (virObjectEventCallbackListRemoveID) (virObjectEventDispatchMatchCallback) (virObjectEventStateRegisterID): Update clients. * src/conf/domain_event.c (virDomainEventCallbackListAdd) (virDomainEventStateRegisterID): Likewise. * src/conf/network_event.c (virNetworkEventStateRegisterID): Likewise. * tests/objecteventtest.c (testDomainCreateXMLMixed): Enhance test. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
Consider these two calls, in either order: id1 = virConnectDomainEventRegisterAny(conn, NULL, VIR_DOMAIN_EVENT_ID_LIFECYCLE, VIR_DOMAIN_EVENT_CALLBACK(callback), NULL, NULL); virConnectDomainEventRegister(conn, callback, NULL, NULL); Right now, the second call fails, because under the hood, the old-style function registration is tightly coupled to the new style lifecycle eventID, and the two calls both try to register the same global eventID callback representation. We've alreay documented that users should avoid old-style registration and deregistration, so anyone heeding the advice won't run into this situation. But it would be even nicer if we pretend the two interfaces are completely separate, and disallow any cross-linking. That is, a call to old-style deregister should never remove a new-style callback even if it is the same function pointer, and a call to new-style callback using only callbackIDs obtained legitimately should never remove an old-style callback (of course, since our callback IDs are sequential, and there is still coupling under the hood, you can easily guess the callbackID of an old style registration and use new-style deregistration to nuke it - but that starts to be blatantly bad coding on your part rather than a surprising result on what looks like reasonable stand-alone API). With this patch, you can now register a global lifecycle event handler twice, by using both old and new APIs; if such an event occurs, your callback will be entered twice. But that is not a problem in practice, since it is already possible to use the new API to register both a global and per-domain event handler using the same function, which will likewise fire your callback twice for that domain. Duplicates are still prevented when using the same API with same parameters twice (old-style twice, new-style global twice, or new-style per-domain with same domain twice), and things are still bounded (it is not possible to register a single function pointer more than N+2 times per event id, where N is the number of domains available on the connection). Besides, it has always been possible to register as many separate function pointers on the same event id as desired, through either old or new style API, where the bound there is the physical limitation of writing a program with enough distinct function pointers. Adding another event registration in the testsuite is sufficient to cover this, where the test fails without the rest of the patch. * src/conf/object_event.c (_virObjectEventCallback): Add field. (virObjectEventCallbackLookup): Add argument. (virObjectEventCallbackListAddID, virObjectEventStateCallbackID): Adjust callers. * tests/objecteventtest.c (testDomainCreateXMLMixed): Enhance test. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
On the surface, this sequence of API calls should succeed: id1 = virConnectDomainEventRegisterAny(..., VIR_DOMAIN_EVENT_ID_LIFECYCLE,...); id2 = virConnectDomainEventRegisterAny(..., VIR_DOMAIN_EVENT_ID_RTC_CHANGE,...); virConnectDomainEventDeregisterAny(id1); id1 = virConnectDomainEventRegisterAny(..., VIR_DOMAIN_EVENT_ID_LIFECYCLE,...); And for test:///default, it does. But for qemu:///system, it fails: libvirt: XML-RPC error : internal error: domain event 0 already registered Looking closer, the bug is caused by miscommunication between the object event engine and the client side of the remote driver. In our implementation, we set up a single server-side event per eventID, then the client side replicates that one event to all callbacks that have been registered client side. To know when to turn the server side eventID on or off, the client side must track how many events for the same eventID have been registered. But while our code was filtering by eventID on event registration, it did not filter on event deregistration. So the above API calls resulted in the deregister returning 1 instead of 0, so no RPC deregister was issued, and the final register detects on the server side that the server is already handling eventID 0. Unfortunately, since the problem is only observable on remote connections, it's not possible to enhance objecteventtest to expose the semantics using only public API entry points. * src/conf/object_event.c (virObjectEventCallbackListCount): New function. (virObjectEventCallbackListAddID) (virObjectEventCallbackListRemoveID) (virObjectEventCallbackListMarkDeleteID): Use it. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Lénaïc Huard 提交于
When the host is configured with very restrictive firewall (default policy is DROP for all chains, including OUTPUT), the bridge driver for Linux adds netfilter entries to allow DHCP and DNS requests to go from the VM to the dnsmasq of the host. The issue that this commit fixes is the fact that a DROP policy on the OUTPUT chain blocks the DHCP replies from the host’s dnsmasq to the VM. As DHCP replies are sent in UDP, they are not caught by any --ctstate ESTABLISHED rule and so, need to be explicitly allowed. Signed-off-by: NLénaïc Huard <lenaic@lhuard.fr.eu.org>
-
When determining if a device is behind a PCI bridge, the PCI device class is checked by reading the config space. However, there are some devices which have the wrong class on the config space, but the class is initialized by Linux correctly as a PCI BRIDGE. This class can be read by the sysfs file '/sys/bus/pci/devices/xxxx:xx:xx.x/class'. One example of such bridge is IBM PCI Bridge 1014:03b9, which is identified as a Host Bridge when reading the config space. Signed-off-by: NThadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
-
由 Eric Blake 提交于
Bah, serves me right for merging patches without one last compile test. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
Tighten up scope after the previous patch avoided using internals. This will also make it easier to change internal implementation without having to chase down quite as many impacted callers or worrying about two files getting implementations out of sync. * src/conf/object_event_private.h (virObjectEventCallbackListAddID, virObjectEventQueueClear) (virObjectEventStateLock, virObjectEventStateUnlock) (virObjectEventTimer): Drop prototype. (_virObjectEventCallbackList, _virObjectEventState) (_virObjectEventCallback): Move... * src/conf/object_event.c: ...here. (virObjectEventCallbackListAddID, virObjectEventQueueClear) (virObjectEventStateLock, virObjectEventStateUnlock) (virObjectEventTimer): Mark private. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
Right now, the older virConnectDomainEventRegister (takes a function pointer, returns 0 on success) and the newer virConnectDomainEventRegisterID (takes an eventID, returns a callbackID) share the underlying implementation (the older API ends up consuming a callbackID for eventID 0 under the hood). We implemented that by a lot of copy and pasted code between object_event.c and domain_event.c, according to whether we are dealing with a function pointer or an eventID. However, our copy and paste is not symmetric. Consider this sequence: id1 = virConnectDomainEventRegisterAny(conn, dom, VIR_DOMAIN_EVENT_ID_LIFECYCLE, VIR_DOMAIN_EVENT_CALLBACK(callback), NULL, NULL); virConnectDomainEventRegister(conn, callback, NULL, NULL); virConnectDomainEventDeregister(conn, callback); virConnectDomainEventDeregsiterAny(conn, id1); the first three calls would succeed, but the third call ended up nuking the id1 callbackID (the per-domain new-style handler), then the fourth call failed with an error about an unknown callbackID, leaving us with the global handler (old-style) still live and receiving events. It required another old-style deregister to clean up the mess. Root cause was that virDomainEventCallbackList{Remove,MarkDelete} were only checking for function pointer match, rather than also checking for whether the registration was global. Rather than playing with the guts of object_event ourselves in domain_event, it is nicer to add a mapping function for the internal callback id, then share common code for event removal. For now, the function-to-id mapping is used only internally; I thought about whether a new public API to let a user learn the callback would be useful, but decided exposing this to the user is probably a disservice, since we already publicly document that they should avoid the old style, and since this patch already demonstrates that older libvirt versions have weird behavior when mixing old and new styles. And like all good bug fix patches, I enhanced the testsuite, validating that the changes in tests/ expose the failure without the rest of the patch. * src/conf/object_event.c (virObjectEventCallbackLookup) (virObjectEventStateCallbackID): New functions. (virObjectEventCallbackLookup): Use helper function. * src/conf/object_event_private.h (virObjectEventStateCallbackID): Declare new function. * src/conf/domain_event.c (virDomainEventStateRegister) (virDomainEventStateDeregister): Let common code handle the complexity. (virDomainEventCallbackListRemove) (virDomainEventCallbackListMarkDelete) (virDomainEventCallbackListAdd): Drop unused functions. * tests/objecteventtest.c (testDomainCreateXMLMixed): New test. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 07 1月, 2014 12 次提交
-
-
由 Eric Blake 提交于
Since the introduction of network events, any driver that uses a single event state object to track both domain and network events should not include 'domain' in the name of that object. * src/test/test_driver.c (_testConn): s/domainEventState/eventState/, and fix all callers. * src/remote/remote_driver.c (private_data): Likewise. (remoteDomainEventQueue): Rename to remoteEventQueue. (remoteDomainEvents): Rename to remoteEvents. Signed-off-by: NEric Blake <eblake@redhat.com>
-
test:///default由 Eric Blake 提交于
Prior to this patch, every test:/// URI has its own event manager, which means that registering for an event can only ever receive events from the connection where it issued the API that triggered the event. But the whole idea of events is to be able to learn about something where an API call did NOT trigger the action. In order to actually test asynchronous events, I wanted to be able to tie multiple test connections to the same state. Use of a file in a test URI is still per-connection state, but now parallel connections to test:///default (from the same binary, of course) now share common state and can affect one another. The updated testsuite fails without the rest of this patch. Valgrind didn't report any leaks. * src/test/test_driver.c (testConnectOpen): Move per-connection state initialization... (testOpenFromFile): ...here. (defaultConn, defaultConnections, defaultLock, testOnceInit): New shared state. (testOpenDefault): Only initialize on first connection. (testConnectClose): Don't clobber state if still shared. * tests/objecteventtest.c (testDomainStartStopEvent): Enhance to cover this. (timeout, mymain): Ensure test fails rather than blocks. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Michal Privoznik 提交于
The argument is --handshakefd not --handshake. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Michal Privoznik 提交于
The @name variable is VIR_STRDUP()-ed into, but never freed. In fact, there's no need to duplicate a command line argument since all places where @name is used expect const char. Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
-
由 Jiri Denemark 提交于
CVE-2013-6458 Every API that is going to begin a job should do that before fetching data from vm->def.
-
由 Jiri Denemark 提交于
Every API that is going to begin a job should do that before fetching data from vm->def.
-
由 Jiri Denemark 提交于
CVE-2013-6458 Every API that is going to begin a job should do that before fetching data from vm->def.
-
由 Jiri Denemark 提交于
CVE-2013-6458 Generally, every API that is going to begin a job should do that before fetching data from vm->def. However, qemuDomainGetBlockInfo does not know whether it will have to start a job or not before checking vm->def. To avoid using disk alias that might have been freed while we were waiting for a job, we use its copy. In case the disk was removed in the meantime, we will fail with "cannot find statistics for device '...'" error message.
-
由 Jiri Denemark 提交于
CVE-2013-6458 https://bugzilla.redhat.com/show_bug.cgi?id=1043069 When virDomainDetachDeviceFlags is called concurrently to virDomainBlockStats: libvirtd may crash because qemuDomainBlockStats finds a disk in vm->def before getting a job on a domain and uses the disk pointer after getting the job. However, the domain in unlocked while waiting on a job condition and thus data behind the disk pointer may disappear. This happens when thread 1 runs virDomainDetachDeviceFlags and enters monitor to actually remove the disk. Then another thread starts running virDomainBlockStats, finds the disk in vm->def, and while it's waiting on the job condition (owned by the first thread), the first thread finishes the disk removal. When the second thread gets the job, the memory pointed to be the disk pointer is already gone. That said, every API that is going to begin a job should do that before fetching data from vm->def.
-
由 Yudai Yamagish 提交于
This patch fixes a segmentation fault when creating new virtual machines using QEMU. The segmentation fault is caused by commit f4183068 and commit cbb6ec42. In virQEMUCapsProbeQMPMachineTypes, when copying machines to qemuCaps, "none" is skipped. Therefore, the value of i and "qemuCaps->nmachineTypes - 1" do not always match. However, defIdx value (used to call virQEMUCapsSetDefaultMachine) is set using the value in i when the array elements are in qemuCaps->nmachineTypes - 1. So, when libvirt tries to create virtual machines using the default machine type, qemuCaps->machineTypes[defIdx] is accessed and since the defIdx is NULL, it results in segmentation fault. Signed-off-by: NYudai Yamagishi <yummy@sfc.wide.ad.jp> Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
-
由 Eric Blake 提交于
Cleanup after commit db3dd082 removed all clients outside of the .h file. * src/datatypes.h (VIR_IS_CONNECT): Delete, and inline into all callers, since no other file uses it any more. Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
Ever since their introduction (commit 1509b802 in v0.5.0 for virConnectDomainEventRegister, commit 44457238 in v0.8.0 for virConnectDomainEventDeregisterAny), the event deregistration functions have been documented as returning 0 on success; likewise for older registration (only the newer RegisterAny must return a non-zero callbackID). And now that we are adding virConnectNetworkEventDeregisterAny for v1.2.1, it should have the same semantics. Fortunately, all of the stateful drivers have been obeying the docs and returning 0, thanks to the way the remote_driver tracks things (in fact, the RPC wire protocol is unable to send a return value for DomainEventRegisterAny, at least not without adding a new RPC number). Well, except for vbox, which was always failing deregistration, due to failure to set the return value to anything besides its initial -1. But for local drivers, such as test:///default, we've been returning non-zero numbers; worse, the non-zero numbers have differed over time. For example, in Fedora 12 (libvirt 0.8.2), calling Register twice would return 0 and 1 [the callbackID generated under the hood]; while in Fedora 20 (libvirt 1.1.3), it returns 1 and 2 [the number of callbacks registered for that event type]. Since we have changed the behavior over time, and since it differs by local vs. remote, we can safely argue that no one could have been reasonably relying on any particular behavior, so we might as well obey the docs, as well as prepare callers that might deal with older clients to not be surprised if the docs are not strictly followed. For consistency, this patch fixes the code for all drivers, even though it only makes an impact for vbox and for local drivers. By fixing all drivers, future copy and paste from a remote driver to a local driver is less likely to reintroduce the bug. Finally, update the testsuite to gain some coverage of the issue for local drivers, including the first test of old-style domain event registration via function pointer instead of event id. * src/libvirt.c (virConnectDomainEventRegister) (virConnectDomainEventDeregister) (virConnectDomainEventDeregisterAny): Clarify docs. * src/libxl/libxl_driver.c (libxlConnectDomainEventRegister) (libxlConnectDomainEventDeregister) (libxlConnectDomainEventDeregisterAny): Match documentation. * src/lxc/lxc_driver.c (lxcConnectDomainEventRegister) (lxcConnectDomainEventDeregister) (lxcConnectDomainEventDeregisterAny): Likewise. * src/test/test_driver.c (testConnectDomainEventRegister) (testConnectDomainEventDeregister) (testConnectDomainEventDeregisterAny) (testConnectNetworkEventDeregisterAny): Likewise. * src/uml/uml_driver.c (umlConnectDomainEventRegister) (umlConnectDomainEventDeregister) (umlConnectDomainEventDeregisterAny): Likewise. * src/vbox/vbox_tmpl.c (vboxConnectDomainEventRegister) (vboxConnectDomainEventDeregister) (vboxConnectDomainEventDeregisterAny): Likewise. * src/xen/xen_driver.c (xenUnifiedConnectDomainEventRegister) (xenUnifiedConnectDomainEventDeregister) (xenUnifiedConnectDomainEventDeregisterAny): Likewise. * src/network/bridge_driver.c (networkConnectNetworkEventDeregisterAny): Likewise. * tests/objecteventtest.c (testDomainCreateXMLOld): New test. (mymain): Run it. (testDomainCreateXML): Check return values. Signed-off-by: NEric Blake <eblake@redhat.com>
-