- 15 6月, 2012 24 次提交
-
-
由 Eric Blake 提交于
Wen Congyang reported that we have a double-close bug if we fail virFDStreamOpenInternal, since childfd duplicated one of the fds[] array contents. In truth, since we always transfer both members of fds to other variables, we should close the fds through those other names, and just use fds[] for pipe(). Bug present since 0.9.0 (commit e886237a). * src/fdstream.c (virFDStreamOpenFileInternal): Swap scope of childfd and fds[], to avoid a double close. (cherry picked from commit f3cfc7c8)
-
由 Eric Blake 提交于
KAMEZAWA Hiroyuki reported a nasty double-free bug when virCommand is used to convert a string into input to a child command. The problem is that the poll() loop of virCommandProcessIO would close() the write end of the pipe in order to let the child see EOF, then the caller virCommandRun() would also close the same fd number, with the second close possibly nuking an fd opened by some other thread in the meantime. This in turn can have all sorts of bad effects. The bug has been present since the introduction of virCommand in commit f16ad06f. This is based on his first attempt at a patch, at https://bugzilla.redhat.com/show_bug.cgi?id=823716 * src/util/command.c (_virCommand): Drop inpipe member. (virCommandProcessIO): Add argument, to avoid closing caller's fd without informing caller. (virCommandRun, virCommandNewArgs): Adjust clients. (cherry picked from commit da831afc) Conflicts: src/util/command.c
-
由 Wen Congyang 提交于
virCommandRunAsync() will set errfd if it succeed. We should close it if virFDStreamOpenInternal() fails. (cherry picked from commit 655cffa0)
-
由 Wen Congyang 提交于
If the system does not support bypass cache, we will close fd, but it is uninitialized. (cherry picked from commit 0a045f01)
-
由 Daniel P. Berrange 提交于
The uhci1, uhci2, uhci3 companion controllers for ehci1 must have a master start port set. Since this value is predictable we should set it automatically if the app does not supply it (cherry picked from commit 03b804a2)
-
由 Daniel P. Berrange 提交于
Currently each USB2 companion controller gets put on a separate PCI slot. Not only is this wasteful of PCI slots, but it is not in compliance with the spec for USB2 controllers. The master echi1 and all companion controllers should be in the same slot, with echi1 in function 7, and uhci1-3 in functions 0-2 respectively. * src/qemu/qemu_command.c: Special case handling of USB2 controllers to apply correct pci slot assignment * tests/qemuxml2argvdata/qemuxml2argv-usb-ich9-ehci-addr.args, tests/qemuxml2argvdata/qemuxml2argv-usb-ich9-ehci-addr.xml: Expand test to cover automatic slot assignment (cherry picked from commit 1ebd52cb) Conflicts: tests/qemuxml2xmltest.c
-
由 Daniel P. Berrange 提交于
The virDomainDeviceInfoIsSet API was only checking if an address or alias was set in the struct. Thus if only a rom bar setting / filename, boot index, or USB master value was set, they could be accidentally dropped when formatting XML (cherry picked from commit 2c195fdb) Conflicts: src/conf/domain_conf.c (crobinso: some elements aren't in maint branch, drop them)
-
由 Serge E. Hallyn 提交于
The glibc ones (intentionally) cannot handle ptys opened in a devpts not mounted at /dev/pts. Drop the (un-exported, unused) virFileOpenTtyAt. Signed-off-by: NSerge Hallyn <serge.hallyn@canonical.com> Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 80710c69) Conflicts: src/lxc/lxc_controller.c
-
由 Stefan Bader 提交于
When using the xm/xend stack to manage instances there is a bug that causes the emulated interfaces to be unusable when the vif config contains type=ioemu. The current code already has a special quirk to not use this keyword if no specific model is given for the emulated NIC (defaulting to rtl8139). Essentially it works because regardless of the type argument,i the Xen stack always creates emulated and paravirt interfaces and lets the guest decide which one to use. So neither xl nor xm stack actually require the type keyword for emulated NICs. Signed-off-by: NStefan Bader <stefan.bader@canonical.com> (cherry picked from commit 10c31135)
-
由 Stefan Bader 提交于
On newer xend (v3.x and after) there is no state and domid reported for inactive domains. When initially creating connections this is handled in various places by assigning domain->id = -1. But once an instance has been running, the id is set to the current domain id. And it does not change when the instance is shut down. So when querying the domain info, the hypervisor driver, which gets asked first will indicate it cannot find information, then the xend driver is asked and will set the status to NOSTATE because it checks for the -1 domain id. Checking domain/status for 0 seems to be more reliable for that. One note: I am not sure whether the domain->id also should get set back to -1 whenever any sub-driver thinks the instance is no longer running. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=746007 BugLink: http://bugs.launchpad.net/bugs/929626Signed-off-by: NStefan Bader <stefan.bader@canonical.com> (cherry picked from commit 26e9ef47) (crobinso: Add Stefan to AUTHORS. maint only)
-
由 Philipp Hahn 提交于
filename is not initialized to NULL while it's unconditionally freed in the error path. Signed-off-by: NPhilipp Hahn <hahn@univention.de> (cherry picked from commit 360afebf)
-
由 Philipp Hahn 提交于
On CentOS5 with xen-3.0.3: Program received signal SIGSEGV, Segmentation fault. virFree (ptrptr=0x8) at util/memory.c:310 310 free(*(void**)ptrptr); (gdb) bt #0 virFree (ptrptr=0x8) at util/memory.c:310 #1 0x00002aaaaae167c8 in xenXMDomainDefineXML (conn=0x694e80, xml=0x6b2ce0 "P\fk") at xen/xm_internal.c:1199 #2 0x00002aaaaae070d7 in xenUnifiedDomainDefineXML (conn=0x8, xml=0x6ac040 "<domain type='xen'>\n <name>pv</name>\n <uuid>20291bc0-453a-4d6c-c6ac-4e5af63b932c</uuid>\n <memory>1048576</memory>\n <currentMemory>1048576</currentMemory>\n <vcpu>1</vcpu>\n <os>\n <type arch='x8"...) at xen/xen_driver.c:1524 #3 0x00002aaaaada7803 in virDomainDefineXML (conn=0x694e80, xml=0x6ac040 "<domain type='xen'>\n <name>pv</name>\n <uuid>20291bc0-453a-4d6c-c6ac-4e5af63b932c</uuid>\n <memory>1048576</memory>\n <currentMemory>1048576</currentMemory>\n <vcpu>1</vcpu>\n <os>\n <type arch='x8"...) at libvirt.c:7823 #4 0x0000000000426173 in cmdEdit (ctl=0x7fffffffb8e0, cmd=<value optimized out>) at virsh.c:14882 #5 0x000000000041c9ce in vshCommandRun (ctl=0x7fffffffb8e0, cmd=0x658c50) at virsh.c:17712 #6 0x000000000042c3b9 in main (argc=1, argv=<value optimized out>) at virsh.c:19317 Signed-off-by: NPhilipp Hahn <hahn@univention.de> (cherry picked from commit 046b0a69)
-
由 Cole Robinson 提交于
It just doesn't really make sense and confuses virt-manager (cherry picked from commit efb0839c) Conflicts: src/xenxs/xen_sxpr.c
-
由 Guido Günther 提交于
On xen 4.1 I observed configurations that look like: (image (hvm (kernel '') (loader '/foo/bar') )) The kernel element is there but unset. This leads to an empty <kernel/> element in the XML and even worse makes us skip the boot order parsing and therefore not emit a <boot device='$dev>'/> element which breaks CD booting. (cherry picked from commit dca1a6b4)
-
由 Guido Günther 提交于
otherwise a missing UUID in a domain config just shows: error: An error occurred, but the cause is unknown Now we have: error: configuration file syntax error: config value uuid was missing (cherry picked from commit c5d2984c)
-
由 Guido Günther 提交于
(cherry picked from commit 6dd8532d)
-
由 Radu Caragea 提交于
The stream lock is unlocked twice instead of being locked and then unlocked. Probably a typo. (cherry picked from commit 107f51b6) Conflicts: AUTHORS
-
由 Peter Krempa 提交于
This patch adds another callback to a FDstream object. The original callback is used by the daemon stream driver to handle events. This callback is called if and only if the stream is about to be closed. This might be used to handle cleanup steps after a fdstream exits. This will be used later on in ensuring mutually exclusive access to consoles. * src/fdstream.c: - emit the callback, when stream is being closed - add data structures needed to handle the callback - add function to register callback * src/fdstream.h: - define function prototypes for the callback (cherry picked from commit 0c4bfdda)
-
由 Peter Krempa 提交于
This patch causes the fdstream driver to call the stream event callback if virStreamAbort() is called on a stream using this driver. A remote handler for a stream can only detect changes via stream events, so this event callback is necessary in order to enable a daemon to abort a stream in such a way that the client will see the change. * src/fdstream.c: - modify close function to call stream event callback (cherry picked from commit 95fdc1bc)
-
由 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 (cherry picked from commit a38710bd)
-
由 Daniel P. Berrange 提交于
Very occasionally the sequence of events from poll would result in getting a HANGUP on its own, instead of a HANGUP+READABLE at the same time. In the former case we would send back an error event to the client, but never send the empty packet to indicate EOF. (cherry picked from commit 1d46b2e9)
-
由 Daniel P. Berrange 提交于
If we receive an error on the stream, set the EOF marker so that any further (bogus) incoming data is dropped. * src/rpc/virnetclientstream.c: Set EOF on stream (cherry picked from commit bc61aa12)
-
由 Marc-André Lureau 提交于
Do not crash if virStreamFinish is called after error. ==11000== Invalid read of size 4 ==11000== at 0x373A8099A0: pthread_mutex_lock (pthread_mutex_lock.c:51) ==11000== by 0x4C7CADE: virMutexLock (threads-pthread.c:85) ==11000== by 0x4D57C31: virNetClientStreamRaiseError (virnetclientstream.c:203) ==11000== by 0x4D385E4: remoteStreamFinish (remote_driver.c:3541) ==11000== by 0x4D182F9: virStreamFinish (libvirt.c:14157) ==11000== by 0x40FDC4: cmdScreenshot (virsh.c:3075) ==11000== by 0x42BA40: vshCommandRun (virsh.c:14922) ==11000== by 0x42ECCA: main (virsh.c:16381) ==11000== Address 0x59b86c0 is 16 bytes inside a block of size 216 free'd ==11000== at 0x4A06928: free (vg_replace_malloc.c:427) ==11000== by 0x4C69E2B: virFree (memory.c:310) ==11000== by 0x4D57B56: virNetClientStreamFree (virnetclientstream.c:184) ==11000== by 0x4D3DB7A: remoteDomainScreenshot (remote_client_bodies.h:1812) ==11000== by 0x4CFD245: virDomainScreenshot (libvirt.c:2903) ==11000== by 0x40FB73: cmdScreenshot (virsh.c:3029) ==11000== by 0x42BA40: vshCommandRun (virsh.c:14922) ==11000== by 0x42ECCA: main (virsh.c:16381) (cherry picked from commit be5ec766)
-
由 Daniel P. Berrange 提交于
commit 984840a2 removed the notification of waiting calls when VIR_NET_CONTINUE messages arrive. This was to fix the case of a virStreamAbort() call being prematurely notified of completion. The problem is that sometimes there are dummy calls from a virStreamRecv() call waiting that *do* need to be notified. These dummy calls should have a status VIR_NET_CONTINUE. So re-add the notification upon VIR_NET_CONTINUE, but only if the waiter also has a status of VIR_NET_CONTINUE. * src/rpc/virnetclient.c: Notify waiting call if stream data arrives * src/rpc/virnetclientstream.c: Mark dummy stream read packet with status VIR_NET_CONTINUE (cherry picked from commit cb610092)
-
- 18 5月, 2012 10 次提交
-
-
由 Eric Blake 提交于
Ever since commit c964b6aa, make was trying to find the timestamp of '""./apibuild.py".stamp"', but only touching 'apibuild.py.stamp', and thus always rebuilding. Reported by Daniel P. Berrange. * docs/Makefile.am (APIBUILD, APIBUILD_STAMP): Omit bogus quotes. (cherry picked from commit c0057d9a)
-
由 Daniel P. Berrange 提交于
Language bindings may well want to use the libvirt-api.xml and libvirt-qemu-api.xml files to either auto-generate themselves, or sanity check the manually written bindings for completeness. Currently these XML files are not installed as standard, merely ending up as a %doc file in the RPM. This changes them to be installed into $prefix/share/libvirt/apis/ The *-refs.xml files are not installed, since those are only useful during generation of the online API doc files. The pkg-config file is enhanced so that you can query the install location of the API files. eg # pkg-config --variable=libvirt_qemu_api libvirt /home/berrange/builder/i686-pc-mingw32/sys-root/mingw/share/libvirt/libvirt-qemu-api.xml * docs/Makefile.am: Install libvirt-api.xml & libvirt-qemu-api.xml * libvirt.pc.in: Add vars for querying API install location * libvirt.spec.in, mingw32-libvirt.spec.in: Include API XML files (cherry picked from commit c95c90ee)
-
由 Eric Blake 提交于
On rawhide, gcc is new enough to output new DWARF information that pdwtags has not yet learned, but the resulting 'make check' output was rather confusing: $ make -C src check ... GEN virkeepaliveprotocol-structs die__process_function: DW_TAG_INVALID (0x4109) @ <0x58c> not handled! WARNING: your pdwtags program is too old WARNING: skipping the virkeepaliveprotocol-structs test WARNING: install dwarves-1.3 or newer ... $ pdwtags --version v1.9 I've filed the pdwtags deficiency as https://bugzilla.redhat.com/show_bug.cgi?id=772358 * src/Makefile.am (PDWTAGS): Don't leave -t file behind on version mismatch. Soften warning message, since 1.9 is newer than 1.3. Don't leak stderr from broken version. (cherry picked from commit cf6d3625)
-
由 Eric Blake 提交于
CC libvirt_driver_xenapi_la-xenapi_driver.lo xenapi/xenapi_driver.c: In function 'xenapiDomainGetVcpus': xenapi/xenapi_driver.c:1209:21: error: variable 'cpus' set but not used [-Werror=unused-but-set-variable] * src/xenapi/xenapi_driver.c (xenapiDomainGetVcpus): Silence compiler warning. (cherry picked from commit 787b0a22)
-
由 Eric Blake 提交于
I got these distcheck failures with sanlock enabled: ERROR: files left in build directory after distclean: ./tools/virt-sanlock-cleanup ./src/locking/qemu-sanlock.conf * src/Makefile.am (DISTCLEANFILES) [HAVE_SANLOCK]: Clean built file. * tools/Makefile.am (DISTCLEANFILES): Likewise. (cherry picked from commit c654ba88) plus tweak to DISTCLEANFILES from commit ddf3bd32, although that full commit is too invasive to backport
-
由 Eric Blake 提交于
I am getting this failure with 'make distcheck': GEN ../../src/remote_protocol-structs /bin/sh: ../../src/remote_protocol-structs-t: Permission denied make[4]: *** [../../src/remote_protocol-structs] Error 1 since it attempts a sub-run of a VPATH 'make check' where $(srcdir) is intentionally read-only. I'm not sure which commit introduced the problem, although I suspect it was around 62dee6fa when I refactored protocol struct checking to be more powerful. $(@F) is required by POSIX, and although it is not yet portable to all make implementations, we already require GNU make. * src/Makefile.am (PDWTAGS): Generate temp file into current directory, since $(srcdir) is read-only during distcheck. (cherry picked from commit 2d45ae5a)
-
由 Cole Robinson 提交于
We were using the libvirt release version (like 0.9.11) and not the configure version (which for stable releases is 0.9.11.X) Most other places got this right so hopefully that's all the fallout from the version format change :) Signed-off-by: NCole Robinson <crobinso@redhat.com> (cherry picked from commit 002b18b3)
-
由 Cole Robinson 提交于
Use a witness file approach like we do for python/generator.py, as suggested by Eric. Fixes the build issue reported here: https://www.redhat.com/archives/libvir-list/2012-April/msg01435.htmlSigned-off-by: NCole Robinson <crobinso@redhat.com> (cherry picked from commit c964b6aa) Conflicts: .gitignore - context with other commits not backported
-
由 Cole Robinson 提交于
Since for stable releases, some test files were over the 99 char limit for traditional tar filenames. Suggested by Osier here: https://www.redhat.com/archives/libvir-list/2012-April/msg01435.htmlSigned-off-by: NCole Robinson <crobinso@redhat.com> (cherry picked from commit ddd6bef4)
-
由 Daniel P. Berrange 提交于
Every now & then, with parallel builds, we get a failure to validate hvsupport.html.in. I eventually noticed that this is because we get 2 instances of the generator running at once. We already list hvsupport.html.in in BUILT_SOURCES but this was not working. It turns out the flaw is that we were adding deps to the 'all:' target instead of the 'all-am:' target. BUILT_SOURCES is a dep of 'all', so any custom targets written in Makefile.am must use 'all-am:' so that they don't get run until BUILT_SOURCES are completely generated * docs/Makefile.am: s/all/all-am/ (cherry picked from commit 4f4b496e) (cherry picked from commit 26fdec39)
-
- 17 5月, 2012 6 次提交
-
-
由 Eric Blake 提交于
I hit a VERY weird testsuite failure on rawhide, which included _binary_ output to stderr, followed by a hang waiting for me to type something! (Here, using ^@ for NUL): $ ./commandtest TEST: commandtest WARNING: gnome-keyring:: couldn't send data: Bad file descriptor .WARNING: gnome-keyring:: couldn't send data: Bad file descriptor .WARNING: gnome-keyring:: couldn't send data: Bad file descriptor WARNING: gnome-keyring:: couldn't send data: Bad file descriptor .8^@^@^@8^@^@^@^A^@^@^@^Bay^A^@^@^@)PRIVATE-GNOME-KEYRING-PKCS11-PROTOCOL-V-1 I finally traced it to the fact that gnome-keyring, called via gnutls_global_init which is turn called by virNetTLSInit, opens an internal fd that it expects to communicate to via a pthread_atfork handler (never mind that it violates POSIX by using non-async-signal-safe functions in that handler: https://bugzilla.redhat.com/show_bug.cgi?id=772320). Our problem stems from the fact that we pulled the rug out from under the library's expectations by closing an fd that it had just opened. While we aren't responsible for fixing the bugs in that pthread_atfork handler, we can at least avoid the bugs by not closing the fd in the first place. * tests/commandtest.c (mymain): Avoid closing fds that were opened by virInitialize. (cherry picked from commit 74ff5750)
-
由 Cole Robinson 提交于
On F16 at least, empty volume groups don't have a directory under /dev. The directory only appears once a logical volume is created. This tickles some behavior in BackendStablePath which ends with libvirt sleeping for 5 seconds while waiting for the directory to appear. This causes all sorts of problems for the virStorageVolLookupByPath API which virtinst uses, even if trying to resolve a path that is independent of the logical pool. In reality we don't even need to do that checking since logical pools always have a stable target path. Short circuit the polling in that case. Fixes bug 782261 (cherry picked from commit 275155f6)
-
由 Peter Krempa 提交于
The init script for the daemon requests to start HAL although it has been deprecated long time ago. This patch removes the dependency. (cherry picked from commit 2dcca3ec)
-
由 Michal Privoznik 提交于
It is a good practise to set revents to zero before doing any poll(). Moreover, we should check if event we waited for really occurred or if any of fds we were polling on didn't encountered hangup. (cherry picked from commit 06b9c5b9)
-
由 Michal Privoznik 提交于
As this is needed. Although some functions check for domain being active before obtaining job, we need to check it after, because obtaining job unlocks domain object, during which a state of domain can be changed. (cherry picked from commit 9bc9999b)
-
由 Daniel P. Berrange 提交于
For unknown reasons, the shunloadtest will crash on Fedora 16 inside dlopen() (gdb) bt #0 0x00000000000050e6 in ?? () #1 0x00007ff61a77b9d5 in floor () from /lib64/libm.so.6 #2 0x00007ff61e522963 in _dl_relocate_object () from /lib64/ld-linux-x86-64.so.2 #3 0x00007ff61e5297e6 in dl_open_worker () from /lib64/ld-linux-x86-64.so.2 #4 0x00007ff61e525006 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #5 0x00007ff61e52917a in _dl_open () from /lib64/ld-linux-x86-64.so.2 #6 0x00007ff61e0f6f26 in dlopen_doit () from /lib64/libdl.so.2 #7 0x00007ff61e525006 in _dl_catch_error () from /lib64/ld-linux-x86-64.so.2 #8 0x00007ff61e0f752f in _dlerror_run () from /lib64/libdl.so.2 #9 0x00007ff61e0f6fc1 in dlopen@@GLIBC_2.2.5 () from /lib64/libdl.so.2 #10 0x0000000000400a15 in main (argc=<optimized out>, argv=<optimized out>) at shunloadtest.c:105 Changing from RTLD_NOW to RTLD_LAZY avoids this problem, but quite possibly does not fix the root cause. * shunloadtest.c: s/NOW/LAZY/ (cherry picked from commit 24d97928)
-