- 08 3月, 2012 2 次提交
-
-
由 Eric Blake 提交于
Commit 5d4b0c4c tried to fix certain classes of VPATH builds, but was too limited. In particular, Guannan Ren reported: > For example: The libvirt source code resides in /home/testuser, > I make dist in /tmp/buildvpath, the XDR routine .c file will > include full path of the header file like: > > #include "/home/testuser/src/rpc/virnetprotocol.h" > #include "internal.h" > #include <arpa/inet.h> > > If we distribute the tarball to another machine to compile, > it will report error as follows: > > rpc/virnetprotocol.c:7:59: fatal error: > /home/testuser/src/rpc/virnetprotocol.h: No such file or directory * src/rpc/genprotocol.pl: Fix more include lines.
-
由 Eric Blake 提交于
On 64-bit platforms, unsigned long and unsigned long long are identical, so we don't have to worry about overflow checks. On 32-bit platforms, anywhere we narrow unsigned long long back to unsigned long, we have to worry about overflow; it's easier to do this in one place by having most of the code use the same or wider types, and only doing the narrowing at the last minute. Therefore, the memory set commands remain unsigned long, and the memory get command now centralizes the overflow check into libvirt.c, so that drivers don't have to repeat the work. This also fixes a bug where xen returned the wrong value on failure (most APIs return -1 on failure, but getMaxMemory must return 0 on failure). * src/driver.h (virDrvDomainGetMaxMemory): Use long long. * src/libvirt.c (virDomainGetMaxMemory): Raise overflow. * src/test/test_driver.c (testGetMaxMemory): Fix driver. * src/rpc/gendispatch.pl (name_to_ProcName): Likewise. * src/xen/xen_hypervisor.c (xenHypervisorGetMaxMemory): Likewise. * src/xen/xen_driver.c (xenUnifiedDomainGetMaxMemory): Likewise. * src/xen/xend_internal.c (xenDaemonDomainGetMaxMemory): Likewise. * src/xen/xend_internal.h (xenDaemonDomainGetMaxMemory): Likewise. * src/xen/xm_internal.c (xenXMDomainGetMaxMemory): Likewise. * src/xen/xm_internal.h (xenXMDomainGetMaxMemory): Likewise. * src/xen/xs_internal.c (xenStoreDomainGetMaxMemory): Likewise. * src/xen/xs_internal.h (xenStoreDomainGetMaxMemory): Likewise. * src/xenapi/xenapi_driver.c (xenapiDomainGetMaxMemory): Likewise. * src/esx/esx_driver.c (esxDomainGetMaxMemory): Likewise. * src/libxl/libxl_driver.c (libxlDomainGetMaxMemory): Likewise. * src/qemu/qemu_driver.c (qemudDomainGetMaxMemory): Likewise. * src/lxc/lxc_driver.c (lxcDomainGetMaxMemory): Likewise. * src/uml/uml_driver.c (umlDomainGetMaxMemory): Likewise.
-
- 05 3月, 2012 1 次提交
-
-
由 Jiri Denemark 提交于
A multi-threaded client with event loop may crash if one of its threads closes a connection while event loop is in the middle of sending keep-alive message (either request or response). The right place for it is inside virNetClientIOEventLoop() between poll() and virNetClientLock(). We should only close a connection directly if no-one is using it and defer the closing to the last user otherwise. So far we only did so if the close was initiated by keep-alive timeout.
-
- 02 3月, 2012 1 次提交
-
-
由 Eric Blake 提交于
Nuke the last vestiges of printing pid_t values with the wrong types, at least in code compiled on mingw64. There may be other places, but for now they are only compiled on systems where the existing %d doesn't trigger gcc warnings. * src/rpc/virnetsocket.c (virNetSocketNew): Use %lld and casting, rather than assuming any particular int type for pid_t. * src/util/command.c (virCommandRunAsync, virPidWait) (virPidAbort): Likewise. (verify): Drop a now stale assertion.
-
- 04 2月, 2012 2 次提交
-
-
由 Philipp Hahn 提交于
compat{a->i}bility erron{->e}ous nec{c->}essary. Either "the" or "a". Signed-off-by: NPhilipp Hahn <hahn@univention.de>
-
由 Eric Blake 提交于
Our HACKING discourages use of malloc and free, for at least a couple of years now. But we weren't enforcing it, until now :) For now, I've exempted python and tests, and will clean those up in subsequent patches. Examples should be permanently exempt, since anyone copying our examples won't have use of our internal-only memory.h via libvirt_util.la. * cfg.mk (sc_prohibit_raw_allocation): New rule. (exclude_file_name_regexp--sc_prohibit_raw_allocation): and exemptions. * src/cpu/cpu.c (cpuDataFree): Avoid false positive. * src/conf/network_conf.c (virNetworkDNSSrvDefParseXML): Fix offenders. * src/libxl/libxl_conf.c (libxlMakeDomBuildInfo, libxlMakeVfb) (libxlMakeDeviceModelInfo): Likewise. * src/rpc/virnetmessage.c (virNetMessageSaveError): Likewise. * tools/virsh.c (_vshMalloc, _vshCalloc): Likewise.
-
- 02 2月, 2012 1 次提交
-
-
由 Eric Blake 提交于
Qemu is adding the ability to do a partial rebase. That is, given: base <- intermediate <- current virDomainBlockPull will produce: current but qemu now has the ability to leave base in the chain, to produce: base <- current Note that current qemu can only do a forward merge, and only with the current image as the destination, which is fully described by this API without flags. But in the future, it may be possible to enhance this API for additional scenarios by using flags: Merging the current image back into a previous image (that is, undoing a live snapshot), could be done by passing base as the destination and flags with a bit requesting a backward merge. Merging any other part of the image chain, whether forwards (the backing image contents are pulled into the newer file) or backwards (the deltas recorded in the newer file are merged back into the backing file), could also be done by passing a new flag that says that base should be treated as an XML snippet rather than an absolute path name, where the XML could then supply the additional instructions of which part of the image chain is being merged into any other part. * include/libvirt/libvirt.h.in (virDomainBlockRebase): New declaration. * src/libvirt.c (virDomainBlockRebase): Implement it. * src/libvirt_public.syms (LIBVIRT_0.9.10): Export it. * src/driver.h (virDrvDomainBlockRebase): New driver callback. * src/rpc/gendispatch.pl (long_legacy): Add exemption. * docs/apibuild.py (long_legacy_functions): Likewise.
-
- 28 1月, 2012 1 次提交
-
-
由 Michal Privoznik 提交于
This API allows a domain to be put into one of S# ACPI states. Currently, S3 and S4 are supported. These states are shared with virNodeSuspendForDuration. However, for now we don't support any duration other than zero. The same apply for flags.
-
- 19 1月, 2012 3 次提交
-
-
由 Daniel P. Berrange 提交于
The RPC generator transforms methods matching certain patterns like 'id' or 'uuid', etc but does not anchor its matches to the end of the word. So if a method contains 'id' in the middle (eg virIdentity) then the RPC generator munges that. * src/rpc/gendispatch.pl: Anchor matches
-
由 Daniel P. Berrange 提交于
To avoid a namespace clash with forthcoming identity APIs, rename the virNet*GetLocalIdentity() APIs to have the form virNet*GetUNIXIdentity() * daemon/remote.c, src/libvirt_private.syms: Update for renamed APIs * src/rpc/virnetserverclient.c, src/rpc/virnetserverclient.h, src/rpc/virnetsocket.c, src/rpc/virnetsocket.h: s/LocalIdentity/UNIXIdentity/
-
由 Daniel P. Berrange 提交于
* daemon/remote.c, src/rpc/virnetserverclient.c, src/rpc/virnetserverclient.h, src/rpc/virnetsocket.c, src/rpc/virnetsocket.h: Add gid parameter
-
- 12 1月, 2012 1 次提交
-
-
由 Michal Privoznik 提交于
If client stream does not have any data to sink and neither received EOF, a dummy packet is sent to the daemon signalising client is ready to sink some data. However, after we added event loop to client a race may occur: Thread 1 calls virNetClientStreamRecvPacket and since no data are cached nor stream has EOF, it decides to send dummy packet to server which will sent some data in turn. However, during this decision and actual message exchange with server - Thread 2 receives last stream data from server. Therefore an EOF is set on stream and if there is a call waiting (which is not yet) it is woken up. However, Thread 1 haven't sent anything so far, so there is no call to be woken up. So this thread sent dummy packet to daemon, which ignores that as no stream is associated with such packet and therefore no reply will ever come. This race causes client to hang indefinitely.
-
- 20 12月, 2011 1 次提交
-
-
由 Eric Blake 提交于
The RPC code had several latent memory leaks and an attempt to free the wrong string, but thankfully nothing triggered them (blkiotune was the only one returning a string, and always as the last parameter). Also, our cleanups for rpcgen ended up nuking a line of code that renders VIR_TYPED_PARAM_INT broken, because it was the only use of 'i' in a function, even though it was a member usage rather than a standalone declaration. * daemon/remote.c (remoteSerializeTypedParameters): Free the correct array element. (remoteDispatchDomainGetSchedulerParameters) (remoteDispatchDomainGetSchedulerParametersFlags) (remoteDispatchDomainBlockStatsFlags) (remoteDispatchDomainGetMemoryParameters): Don't leak strings. * src/rpc/genprotocol.pl: Don't nuke member-usage of 'buf' or 'i'.
-
- 08 12月, 2011 2 次提交
-
-
由 Daniel P. Berrange 提交于
When one thread passes the buck to another thread, it uses virCondSignal to wake up the target thread. The variable 'haveTheBuck' is not updated in a race-free manner when this occurs. The current thread sets it to false, and the woken up thread sets it to true. There is a window where a 3rd thread can come in and grab the buck. Even if this didn't lead to crashes & deadlocks, this would still result in unfairness in the buckpassing algorithm. A better solution is to *never* set haveTheBuck to false when we're passing the buck. Only set it to false when there is no further thread waiting for the buck. * src/rpc/virnetclient.c: Only set haveTheBuck to false if no thread is waiting
-
由 Daniel P. Berrange 提交于
Commit fd066925 tried to fix a race condition in commit fa959500 Author: Daniel P. Berrange <berrange@redhat.com> Date: Fri Nov 11 15:28:41 2011 +0000 Explicitly track whether the buck is held in remote client Unfortunately there is a second race condition whereby the event loop can trigger due to incoming data to read. Revert this fix, so a complete fix for the problem can be cleanly applied * src/rpc/virnetclient.c: Revert fd066925
-
- 07 12月, 2011 1 次提交
-
-
由 Daniel P. Berrange 提交于
Currently if you try to connect to a local libvirtd when libvirtd is not in $PATH, you'll get an error error: internal error invalid use of command API This is because remoteFindDaemonPath() returns NULL, which causes us to pass NULL into virNetSocketConnectUNIX which in turn causes us to pass NULL into virCommandNewArgList. Adding missing error checks improves this to error: internal error Unable to locate libvirtd daemon in $PATH * src/remote/remote_driver.c: Report error if libvirtd cannot be found * src/rpc/virnetsocket.c: Report error if caller requested spawning of daemon, but provided no binary path
-
- 04 12月, 2011 2 次提交
-
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=648855 mentioned a misuse of 'an' where 'a' is proper; that has since been fixed, but a search found other problems (some were a spelling error for 'and', while most were fixed by 'a'). * daemon/stream.c: Fix grammar. * src/conf/domain_conf.c: Likewise. * src/conf/domain_event.c: Likewise. * src/esx/esx_driver.c: Likewise. * src/esx/esx_vi.c: Likewise. * src/rpc/virnetclient.c: Likewise. * src/rpc/virnetserverprogram.c: Likewise. * src/storage/storage_backend_fs.c: Likewise. * src/util/conf.c: Likewise. * src/util/dnsmasq.c: Likewise. * src/util/iptables.c: Likewise. * src/xen/xen_hypervisor.c: Likewise. * src/xen/xend_internal.c: Likewise. * src/xen/xs_internal.c: Likewise. * tools/virsh.c: Likewise.
-
由 Eric Blake 提交于
The RPC fixups needed on Linux are also needed on cygwin, and worked without further tweaking to the list of fixups. Also, unlike BSD, Cygwin exports 'struct ifreq', but unlike Linux, Cygwin lacks the ioctls that we were using 'struct ifreq' to access. This patch allows compilation under cygwin. * src/rpc/genprotocol.pl: Also perform fixups on cygwin. * src/util/virnetdev.c (HAVE_STRUCT_IFREQ): Also require AF_PACKET definition. * src/util/virnetdevbridge.c (virNetDevSetupControlFull): Only compile if SIOCBRADDBR works.
-
- 02 12月, 2011 1 次提交
-
-
由 Peter Krempa 提交于
Originaly, the code checked if another client is the queue and infered ownership of the buck from that. Commit fa959500 added a separate variable to track the buck. That caused, that a new call might enter claiming it has the buck, while another thread was signalled to take the buck. This ends in two threads claiming they hold the buck and entering poll(). This happens due to a race on waking up threads on the client lock mutex. This caused multi-threaded clients to hang, most prominently visible and reproducible on python based clients, like virt-manager. This patch causes threads, that have been signalled to take the buck to re-check if buck is held by another thread.
-
- 01 12月, 2011 1 次提交
-
-
由 Alex Jia 提交于
Detected by Coverity. Leak introduced in commit 673adba5. Two separate bugs here: 1. call was not freed on all error paths 2. virCondDestroy was called even if virCondInit failed Signed-off-by: NAlex Jia <ajia@redhat.com> Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 29 11月, 2011 2 次提交
-
-
由 Jiri Denemark 提交于
When another thread was dispatching while we wanted to send a non-blocking call, we correctly queued the call and woke up the thread but the thread just threw the call away since it forgot to recheck if its socket was writable.
-
由 Christian Franke 提交于
When spawning an ssh connection, the environment variables DISPLAY, SSH_ASKPASS, ... are passed. However XAUTHORITY, which is necessary if the .Xauthority is in a non default place, was not passed. Signed-off-by: NChristian Franke <nobody@nowhere.ws>
-
- 24 11月, 2011 10 次提交
-
-
由 Jiri Denemark 提交于
-
由 Jiri Denemark 提交于
-
由 Jiri Denemark 提交于
-
由 Jiri Denemark 提交于
-
由 Jiri Denemark 提交于
These APIs are used by both client and server RPC layer to handle processing of keepalive messages.
-
由 Jiri Denemark 提交于
The keepalive program has two procedures: PING, and PONG. Both are used only in asynchronous messages and the sender doesn't wait for any reply. However, the party which receives PING messages is supposed to react by sending PONG message the other party, but no explicit binding between PING and PONG messages is made. For backward compatibility neither server nor client are allowed to send keepalive messages before checking that remote party supports them.
-
由 Jiri Denemark 提交于
-
由 Jiri Denemark 提交于
When virNetClientIOEventLoop is called for a non-blocking call and not even a single byte can be sent from this call without blocking, we properly reported that to the caller which properly frees the call. But we never removed the call from a call queue.
-
由 Jiri Denemark 提交于
-
由 Jiri Denemark 提交于
-
- 16 11月, 2011 7 次提交
-
-
由 Daniel P. Berrange 提交于
Due to the asynchronous nature of streams, we might continue to receive some stream packets from the server even after we have shutdown the stream on the client side. These should be discarded silently, rather than raising an error in the RPC layer. * src/rpc/virnetclient.c: Discard stream data silently
-
由 Daniel P. Berrange 提交于
Add a new virNetClientSendNonBlock which returns 2 on full send, 1 on partial send, 0 on no send, -1 on error If a partial send occurs, then a subsequent call to any of the virNetClientSend* APIs will finish any outstanding I/O. TODO: the virNetClientEvent event handler could be used to speed up completion of partial sends if an event loop is present. * src/rpc/virnetsocket.h, src/rpc/virnetsocket.c: Add new virNetSocketHasPendingData() API to test for cached data pending send. * src/rpc/virnetclient.c, src/rpc/virnetclient.h: Add new virNetClientSendNonBlock() API to send non-blocking API
-
由 Daniel P. Berrange 提交于
* src/rpc/virnetclient.c: Add helper for setting I/O callback events
-
由 Daniel P. Berrange 提交于
Stop multiplexing virNetClientSend for two different purposes, instead add virNetClientSendWithReply and virNetClientSendNoReply * src/rpc/virnetclient.c, src/rpc/virnetclient.h: Replace virNetClientSend with virNetClientSendWithReply and virNetClientSendNoReply * src/rpc/virnetclientprogram.c, src/rpc/virnetclientstream.c: Update for new API names
-
由 Daniel P. Berrange 提交于
Remove some duplication by pulling the code for passing the buck out into a helper method * src/rpc/virnetclient.c: Introduce virNetClientIOEventLoopPassTheBuck
-
由 Daniel P. Berrange 提交于
Instead of inferring whether the buck is held from the waitDispatch pointer, use an explicit 'bool haveTheBuck' field * src/rpc/virnetclient.c: Explicitly track the buck
-
由 Daniel P. Berrange 提交于
Directly messing around with the linked list is potentially dangerous. Introduce some helper APIs to deal with list manipulating the list * src/rpc/virnetclient.c: Create linked list handlers
-
- 15 11月, 2011 1 次提交
-
-
由 Daniel P. Berrange 提交于
The src/util/network.c file is a dumping ground for many different APIs. Split it up into 5 pieces, along functional lines - src/util/virnetdevbandwidth.c: virNetDevBandwidth type & helper APIs - src/util/virnetdevvportprofile.c: virNetDevVPortProfile type & helper APIs - src/util/virsocketaddr.c: virSocketAddr and APIs - src/conf/netdev_bandwidth_conf.c: XML parsing / formatting for virNetDevBandwidth - src/conf/netdev_vport_profile_conf.c: XML parsing / formatting for virNetDevVPortProfile * src/util/network.c, src/util/network.h: Split into 5 pieces * src/conf/netdev_bandwidth_conf.c, src/conf/netdev_bandwidth_conf.h, src/conf/netdev_vport_profile_conf.c, src/conf/netdev_vport_profile_conf.h, src/util/virnetdevbandwidth.c, src/util/virnetdevbandwidth.h, src/util/virnetdevvportprofile.c, src/util/virnetdevvportprofile.h, src/util/virsocketaddr.c, src/util/virsocketaddr.h: New pieces * daemon/libvirtd.h, daemon/remote.c, src/conf/domain_conf.c, src/conf/domain_conf.h, src/conf/network_conf.c, src/conf/network_conf.h, src/conf/nwfilter_conf.h, src/esx/esx_util.h, src/network/bridge_driver.c, src/qemu/qemu_conf.c, src/rpc/virnetsocket.c, src/rpc/virnetsocket.h, src/util/dnsmasq.h, src/util/interface.h, src/util/iptables.h, src/util/macvtap.c, src/util/macvtap.h, src/util/virnetdev.h, src/util/virnetdevtap.c, tools/virsh.c: Update include files
-