- 02 8月, 2013 2 次提交
-
-
由 Cole Robinson 提交于
-
由 Ján Tomko 提交于
Call virLogVMessage instead of virLogMessage, since libudev called us with a va_list object, not a list of arguments. Honor message priority and strip the trailing newline. https://bugzilla.redhat.com/show_bug.cgi?id=969152 (cherry picked from commit f753dd62) Conflicts: src/libvirt_private.syms src/node_device/node_device_udev.c src/util/logging.c src/util/logging.h
-
- 23 7月, 2013 7 次提交
-
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=964358 Attempts to start a domain with both SELinux and DAC security modules loaded will deadlock; latent problem introduced in commit fdb3bde3 and exposed in commit 29fe5d74. Basically, when recursing into the security manager for other driver's prefork, we have to undo the asymmetric lock taken at the manager level. Reported by Jiri Denemark, with diagnosis help from Dan Berrange. * src/security/security_stack.c (virSecurityStackPreFork): Undo extra lock grabbed during recursion. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit bfc183c1)
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=964358 Commit 75c12564 states that virGetGroupList must not be called between fork and exec, then commit ee777e99 promptly violated that for lxc's use of virSecurityManagerSetProcessLabel. Hoist the supplemental group detection to the time that the security manager needs to fork. Qemu is safe, as it uses virSecurityManagerSetChildProcessLabel which in turn uses virCommand to determine supplemental groups. This does not fix the fact that virSecurityManagerSetProcessLabel calls virSecurityDACParseIds calls parseIds which eventually calls getpwnam_r, which also violates fork/exec async-signal-safe safety rules, but so far no one has complained of hitting deadlock in that case. * src/security/security_dac.c (_virSecurityDACData): Track groups in private data. (virSecurityDACPreFork): New function, to set them. (virSecurityDACClose): Clean up new fields. (virSecurityDACGetIds): Alter signature. (virSecurityDACSetSecurityHostdevLabelHelper) (virSecurityDACSetChardevLabel, virSecurityDACSetProcessLabel) (virSecurityDACSetChildProcessLabel): Update callers. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 29fe5d74) Conflicts: src/security/security_dac.c - virSecurityDACSetSecurityUSBLabel needed similar treatment; no virSecurityDACSetChildPrcessLabel
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=964358 A future patch wants the DAC security manager to be able to safely get the supplemental group list for a given uid, but at the time of a fork rather than during initialization so as to pick up on live changes to the system's group database. This patch adds the framework, including the possibility of a pre-fork callback failing. For now, any driver that implements a prefork callback must be robust against the possibility of being part of a security stack where a later element in the chain fails prefork. This means that drivers cannot do any action that requires a call to postfork for proper cleanup (no grabbing a mutex, for example). If this is too prohibitive in the future, we would have to switch to a transactioning sequence, where each driver has (up to) 3 callbacks: PreForkPrepare, PreForkCommit, and PreForkAbort, to either clean up or commit changes made during prepare. * src/security/security_driver.h (virSecurityDriverPreFork): New callback. * src/security/security_manager.h (virSecurityManagerPreFork): Change signature. * src/security/security_manager.c (virSecurityManagerPreFork): Optionally call into driver, and allow returning failure. * src/security/security_stack.c (virSecurityDriverStack): Wrap the handler for the stack driver. * src/qemu/qemu_process.c (qemuProcessStart): Adjust caller. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit fdb3bde3) Conflicts: src/security/security_manager.c - context from previous backport differences
-
由 Daniel P. Berrange 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=964358 The hook scripts used by virCommand must be careful wrt accessing any mutexes that may have been held by other threads in the parent process. With the recent refactoring there are 2 potential flaws lurking, which will become real deadlock bugs once the global QEMU driver lock is removed. Remove use of the QEMU driver lock from the hook function by passing in the 'virQEMUDriverConfigPtr' instance directly. Add functions to the virSecurityManager to be invoked before and after fork, to ensure the mutex is held by the current thread. This allows it to be safely used in the hook script in the child process. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 61b52d2e) Conflicts: src/libvirt_private.syms - context src/qemu/qemu_process.c - no backport of qemud_driver struct rename src/security/security_manager.c - no backport of making the security driver self-locking; just expose the interface
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=964358 POSIX states that multi-threaded apps should not use functions that are not async-signal-safe between fork and exec, yet we were using getpwuid_r and initgroups. Although rare, it is possible to hit deadlock in the child, when it tries to grab a mutex that was already held by another thread in the parent. I actually hit this deadlock when testing multiple domains being started in parallel with a command hook, with the following backtrace in the child: Thread 1 (Thread 0x7fd56bbf2700 (LWP 3212)): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 #1 0x00007fd5761e7388 in _L_lock_854 () from /lib64/libpthread.so.0 #2 0x00007fd5761e7257 in __pthread_mutex_lock (mutex=0x7fd56be00360) at pthread_mutex_lock.c:61 #3 0x00007fd56bbf9fc5 in _nss_files_getpwuid_r (uid=0, result=0x7fd56bbf0c70, buffer=0x7fd55c2a65f0 "", buflen=1024, errnop=0x7fd56bbf25b8) at nss_files/files-pwd.c:40 #4 0x00007fd575aeff1d in __getpwuid_r (uid=0, resbuf=0x7fd56bbf0c70, buffer=0x7fd55c2a65f0 "", buflen=1024, result=0x7fd56bbf0cb0) at ../nss/getXXbyYY_r.c:253 #5 0x00007fd578aebafc in virSetUIDGID (uid=0, gid=0) at util/virutil.c:1031 #6 0x00007fd578aebf43 in virSetUIDGIDWithCaps (uid=0, gid=0, capBits=0, clearExistingCaps=true) at util/virutil.c:1388 #7 0x00007fd578a9a20b in virExec (cmd=0x7fd55c231f10) at util/vircommand.c:654 #8 0x00007fd578a9dfa2 in virCommandRunAsync (cmd=0x7fd55c231f10, pid=0x0) at util/vircommand.c:2247 #9 0x00007fd578a9d74e in virCommandRun (cmd=0x7fd55c231f10, exitstatus=0x0) at util/vircommand.c:2100 #10 0x00007fd56326fde5 in qemuProcessStart (conn=0x7fd53c000df0, driver=0x7fd55c0dc4f0, vm=0x7fd54800b100, migrateFrom=0x0, stdin_fd=-1, stdin_path=0x0, snapshot=0x0, vmop=VIR_NETDEV_VPORT_PROFILE_OP_CREATE, flags=1) at qemu/qemu_process.c:3694 ... The solution is to split the work of getpwuid_r/initgroups into the unsafe portions (getgrouplist, called pre-fork) and safe portions (setgroups, called post-fork). * src/util/virutil.h (virSetUIDGID, virSetUIDGIDWithCaps): Adjust signature. * src/util/virutil.c (virSetUIDGID): Add parameters. (virSetUIDGIDWithCaps): Adjust clients. * src/util/vircommand.c (virExec): Likewise. * src/util/virfile.c (virFileAccessibleAs, virFileOpenForked) (virDirCreate): Likewise. * src/security/security_dac.c (virSecurityDACSetProcessLabel): Likewise. * src/lxc/lxc_container.c (lxcContainerSetID): Likewise. * configure.ac (AC_CHECK_FUNCS_ONCE): Check for setgroups, not initgroups. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit ee777e99) Conflicts: src/lxc/lxc_container.c - did not use setUIDGID before 1.1.0 src/util/virutil.c - oom handling changes not backported; no virSetUIDGIDWithCaps src/util/virfile.c - functions still lived in virutil.c this far back configure.ac - context with previous commit src/util/command.c - no UID/GID handling in vircommand.c... src/storage/storage_backend.c - ...so do it in the one hook user instead
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=964358 Since neither getpwuid_r() nor initgroups() are safe to call in between fork and exec (they obtain a mutex, but if some other thread in the parent also held the mutex at the time of the fork, the child will deadlock), we have to split out the functionality that is unsafe. At least glibc's initgroups() uses getgrouplist under the hood, so the ideal split is to expose getgrouplist for use before a fork. Gnulib already gives us a nice wrapper via mgetgroups; we wrap it once more to look up by uid instead of name. * bootstrap.conf (gnulib_modules): Add mgetgroups. * src/util/virutil.h (virGetGroupList): New declaration. * src/util/virutil.c (virGetGroupList): New function. * src/libvirt_private.syms (virutil.h): Export it. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 75c12564) Conflicts: bootstrap.conf - not updating gnulib submodule... configure.ac - ...so checking for getgrouplist by hand... src/util/virutil.c - ...and copying only the getgrouplist implementation rather than calling the gnulib function; also, file still named util.c src/libvirt_private.syms - context
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=964358 A future patch needs to look up pw_gid; but it is wasteful to crawl through getpwuid_r twice for two separate pieces of information, and annoying to copy that much boilerplate code for doing the crawl. The current internal-only virGetUserEnt is also a rather awkward interface; it's easier to just design it to let callers request multiple pieces of data as needed from one traversal. And while at it, I noticed that virGetXDGDirectory could deref NULL if the getpwuid_r lookup fails. * src/util/virutil.c (virGetUserEnt): Alter signature. (virGetUserDirectory, virGetXDGDirectory, virGetUserName): Adjust callers. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit c1983ba4) Conflicts: src/util/virutil.c - oom reporting/strdup changes not backported
-
- 11 7月, 2013 1 次提交
-
-
由 Ján Tomko 提交于
Don't reuse the return value of virStorageBackendFileSystemIsMounted. If it's 0, we'd return it even if the mount command failed. Also, don't report another error if it's -1, since one has already been reported. Introduced by 258e06c8. https://bugzilla.redhat.com/show_bug.cgi?id=981251 (cherry picked from commit 13fde7ce)
-
- 26 6月, 2013 2 次提交
-
-
由 Ján Tomko 提交于
Don't check for '\n' at the end of file if zero bytes were read. Found by valgrind: ==404== Invalid read of size 1 ==404== at 0x529B09F: virCgroupGetValueStr (vircgroup.c:540) ==404== by 0x529AF64: virCgroupMoveTask (vircgroup.c:1079) ==404== by 0x1EB475: qemuSetupCgroupForEmulator (qemu_cgroup.c:1061) ==404== by 0x1D9489: qemuProcessStart (qemu_process.c:3801) ==404== by 0x18557E: qemuDomainObjStart (qemu_driver.c:5787) ==404== by 0x190FA4: qemuDomainCreateWithFlags (qemu_driver.c:5839) Introduced by 0d0b4098. https://bugzilla.redhat.com/show_bug.cgi?id=978356 (cherry picked from commit 306c49ff)
-
由 Ján Tomko 提交于
Free the old XML strings before overwriting them if the user has chosen to reedit the file or force the redefinition. Found by Alex Jia trying to reproduce another bug: https://bugzilla.redhat.com/show_bug.cgi?id=977430#c3 (cherry picked from commit 1e3a2529)
-
- 13 6月, 2013 6 次提交
-
-
由 Cole Robinson 提交于
-
由 Cole Robinson 提交于
If we are just ejecting media, ret == -1 even after the retry loop determines that the tray is open, as requested. This means media disconnect always report's error. Fix it, and fix some other mini issues: - Don't overwrite the 'eject' error message if the retry loop fails - Move the retries decrement inside the loop, otherwise the final loop might succeed, yet retries == 0 and we will raise error - Setting ret = -1 in the disk->src check is unneeded - Fix comment typos cc: mprivozn@redhat.com (cherry picked from commit 406d8a98)
-
由 Michal Privoznik 提交于
In 84c59ffa I've tried to fix changing ejectable media process. The process should go like this: 1) we need to call 'eject' on the monitor 2) we should wait for 'DEVICE_TRAY_MOVED' event 3) now we can issue 'change' command However, while waiting in step 2) the domain monitor was locked. So even if qemu reported the desired event, the proper callback was not called immediately. The monitor handling code needs to lock the monitor in order to read the event. So that's the first lock we must not hold while waiting. The second one is the domain lock. When monitor handling code reads an event, the appropriate callback is called then. The first thing that each callback does is locking the corresponding domain as a domain or its device is about to change state. So we need to unlock both monitor and VM lock. Well, holding any lock while sleep()-ing is not the best thing to do anyway. (cherry picked from commit 543af79a) Conflicts: src/qemu/qemu_hotplug.c
-
由 Michal Privoznik 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=892289 It seems like with new udev within guest OS, the tray is locked, so we need to: - 'eject' - wait for tray to open - 'change' Moreover, even when doing bare 'eject', we should check for 'tray_open' as guest may have locked the tray. However, the waiting phase shouldn't be unbounded, so I've chosen 10 retries maximum, each per 500ms. This should give enough time for guest to eject a media and open the tray. (cherry picked from commit 84c59ffa)
-
由 Stefan Berger 提交于
This patch is in relation to Bug 966449: https://bugzilla.redhat.com/show_bug.cgi?id=966449 This is a patch addressing the coredump. Thread 1 must be calling nwfilterDriverRemoveDBusMatches(). It does so with nwfilterDriverLock held. In the patch below I am now moving the nwfilterDriverLock(driverState) further up so that the initialization, which seems to either take a long time or is entirely stuck, occurs with the lock held and the shutdown cannot occur at the same time. Remove the lock in virNWFilterDriverIsWatchingFirewallD to avoid double-locking. (cherry picked from commit 0ec376c2)
-
由 Christophe Fergeau 提交于
qemu-img resize will fail with "The new size must be a multiple of 512" if libvirt doesn't round it first. This fixes rhbz#951495 Signed-off-by: NChristophe Fergeau <cfergeau@redhat.com> (cherry picked from commit 9a8f39d0)
-
- 12 6月, 2013 2 次提交
-
-
由 Daniel P. Berrange 提交于
Typically when you get EOF on a stream, poll will return POLLIN|POLLHUP at the same time. Thus when we deal with stream reads, if we see EOF during the read, we can then clear the VIR_STREAM_EVENT_HANGUP & VIR_STREAM_EVENT_ERROR event bits. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit e7b03829)
-
由 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)
-
- 25 5月, 2013 1 次提交
-
-
由 Eric Blake 提交于
The previous commit was an incomplete backport of commit 83e4c775, and as a result made any attempt to start a domain when cgroups are enabled go into an infinite loop. This fixes the botched backport. Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 22 5月, 2013 3 次提交
-
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=965169 documents a problem starting domains when cgroups are enabled; I was able to reliably reproduce the race about 5% of the time when I added hooks to domain startup by 3 seconds (as that seemed to be about the length of time that qemu created and then closed a temporary thread, probably related to aio handling of initially opening a disk image). The problem has existed since we introduced virCgroupMoveTask in commit 91028296 (v0.10.0). There are some inherent TOCTTOU races when moving tasks between kernel cgroups, precisely because threads can be created or completed in the window between when we read a thread id from the source and when we write to the destination. As the goal of virCgroupMoveTask is merely to move ALL tasks into the new cgroup, it is sufficient to iterate until no more threads are being created in the old group, and ignoring any threads that die before we can move them. It would be nicer to start the threads in the right cgroup to begin with, but by default, all child threads are created in the same cgroup as their parent, and we don't want vcpu child threads in the emulator cgroup, so I don't see any good way of avoiding the move. It would also be nice if the kernel were to implement something like rename() as a way to atomically move a group of threads from one cgroup to another, instead of forcing a window where we have to read and parse the source, then format and write back into the destination. * src/util/vircgroup.c (virCgroupAddTaskStrController): Ignore ESRCH, because a thread ended between read and write attempts. (virCgroupMoveTask): Loop until all threads have moved. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 83e4c775) Conflicts: src/util/cgroup.c - refactoring in commit 56f27b3b is too big to take in entirety; but I did inline its changes to the cleanup label
-
由 Daniel P. Berrange 提交于
The code for putting the emulator threads in a separate cgroup would spam the logs with warnings 2013-02-27 16:08:26.731+0000: 29624: warning : virCgroupMoveTask:887 : no vm cgroup in controller 3 2013-02-27 16:08:26.731+0000: 29624: warning : virCgroupMoveTask:887 : no vm cgroup in controller 4 2013-02-27 16:08:26.732+0000: 29624: warning : virCgroupMoveTask:887 : no vm cgroup in controller 6 This is because it has only created child cgroups for 3 of the controllers, but was trying to move the processes from all the controllers. The fix is to only try to move threads in the controllers we actually created. Also remove the warning and make it return a hard error to avoid such lazy callers in the future. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 279336c5)
-
由 Daniel P. Berrange 提交于
The QEMU driver has a list of devices nodes that are whitelisted for all guests. The kernel has recently started returning an error if you try to whitelist a device which does not exist. This causes a warning in libvirt logs and an audit error for any missing devices. eg 2013-02-27 16:08:26.515+0000: 29625: warning : virDomainAuditCgroup:451 : success=no virt=kvm resrc=cgroup reason=allow vm="vm031714" uuid=9d8f1de0-44f4-a0b1-7d50-e41ee6cd897b cgroup="/sys/fs/cgroup/devices/libvirt/qemu/vm031714/" class=path path=/dev/kqemu rdev=? acl=rw Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 7f544a4c)
-
- 20 5月, 2013 2 次提交
-
-
由 Cole Robinson 提交于
-
由 Daniel P. Berrange 提交于
When given a CA cert with basic constraints to set non-critical, and key usage of 'key signing', this should be rejected. Version of GNUTLS < 3 do not rejecte it though, so we never noticed the test case was broken Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 0204d6d7)
-
- 16 5月, 2013 1 次提交
-
- 07 5月, 2013 3 次提交
-
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=924501 tracks a problem that occurs if uid 107 is already in use at the time libvirt is first installed. In response that problem, Fedora packaging guidelines were recently updated. This fixes the spec file to comply with the new guidelines: https://fedoraproject.org/wiki/Packaging:UsersAndGroups * libvirt.spec.in (daemon): Follow updated Fedora guidelines. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit a2584d58) Conflicts: libvirt.spec.in - no backport of c8f79c9b %if reindents
-
由 Jiri Denemark 提交于
When a changelog entry references an RPM macro, % needs to be escaped so that it does not appear expanded in package changelog. Fri Mar 4 2009 is incorrect since Mar 4 was Wednesday. Since libvirt-0.6.1 was released on Mar 4 2009, we should change Fri to Wed. (cherry picked from commit 53657a0a)
-
由 Jiri Denemark 提交于
The macro was made to help installing broken packages that did not use DESTDIR correctly by overriding individual path variables (prefix, sysconfdir, ...). Newer rpm provides fixed make_install macro that calls make install with just the correct DESTDIR, however it is not available everywhere (e.g., RHEL 5 does not have it). On the other hand the make_install macro is simple and straightforward enough for us to use its expansion directly. (cherry picked from commit d45066a5)
-
- 23 4月, 2013 2 次提交
-
-
由 Eric Blake 提交于
https://bugzilla.redhat.com/show_bug.cgi?id=922186 Commit d04916fa introduced a regression in audit quality - even though the code was computing the proper escaped name for a path, it wasn't feeding that escaped name on to the audit message. As a result, /var/log/audit/audit.log would mention a pair of fields class=path path=/dev/hpet instead of the intended class=path path="/dev/hpet", which in turn caused ausearch to format the audit log with path=(null). * src/conf/domain_audit.c (virDomainAuditCgroupPath): Use constructed encoding. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 31c6bf35)
-
由 Atsushi Kumagai 提交于
When virStorageBackendLogicalCreateVol() creates a snapshot for a logical volume with backingStore element, it fails with the message below: 2013-01-17 03:10:18.869+0000: 1967: error : virCommandWait:2345 : internal error Child process (/sbin/lvcreate --name lvm-snapshot -L 51200K -s=/dev/lvm-pool/lvm-volume) unexpected exit status 3: /sbin/lvcreate: invalid option -- '=' Error during parsing of command line. This is because virCommandAddArgPair() uses '=' to connect the two parameters, it's unsuitable for -s option of the lvcreate. Signed-off-by: NAtsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp> (cherry picked from commit ffee627a)
-
- 02 4月, 2013 1 次提交
-
-
由 Cole Robinson 提交于
-
- 01 4月, 2013 4 次提交
-
-
由 Matthias Bolte 提交于
Avoid requesting information such as identity or power state when it is not necessary. Lookup virtual machine list with the required fields (configStatus, name, and config.uuid) to make esxVI_GetVirtualMachineIdentity work. No need to call esxVI_GetNumberOfSnapshotTrees. rootSnapshotTreeList can be tested for emptiness by checking it for NULL. esxVI_LookupRootSnapshotTreeList already does the error reporting, don't overwrite it. Check if autostart is enabled at all before looking up the individual autostart setting of a virtual machine. Reorder VIR_EXPAND_N(doms, ndoms, 1) to avoid leaking the result of the call to virGetDomain if VIR_EXPAND_N fails. Replace VIR_EXPAND_N by VIR_RESIZE_N to avoid quadratic scaling, as in the Hyper-V version of the function. If virGetDomain fails it already reports an error, don't overwrite it with an OOM error. All items in doms up to the count-th one are valid, no need to double check before freeing them. Finally, don't leak autoStartDefaults and powerInfoList. (cherry picked from commit 5fc663d8)
-
由 Daniel P. Berrange 提交于
Normally libvirtd should run with a SELinux label system_u:system_r:virtd_t:s0-s0:c0.c1023 If a user manually runs libvirtd though, it is sometimes possible to get into a situation where it is running system_u:system_r:init_t:s0 The SELinux security driver isn't expecting this and can't parse the security label since it lacks the ':c0.c1023' part causing it to complain internal error Cannot parse sensitivity level in s0 This updates the parser to cope with this, so if no category is present, libvirtd will hardcode the equivalent of c0.c1023. Now this won't work if SELinux is in Enforcing mode, but that's not an issue, because the user can only get into this problem if in Permissive mode. This means they can now start VMs in Permissive mode without hitting that parsing error Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 1732c1c6) Conflicts: src/security/security_selinux.c
-
由 Daniel P. Berrange 提交于
Pull the code which parses the current process MCS range out of virSecuritySELinuxMCSFind and into a new method virSecuritySELinuxMCSGetProcessRange. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 4a92fe44) Conflicts: src/security/security_selinux.c
-
由 Daniel P. Berrange 提交于
The body of the loop in virSecuritySELinuxMCSFind would directly 'return NULL' on OOM, instead of jumping to the cleanup label. This caused a leak of several local vars. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit f2d8190c)
-
- 27 3月, 2013 3 次提交
-
-
由 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> (cherry picked from commit ceb31795)
-
由 Eric Blake 提交于
Commit c308a9ae was incomplete; it resolved the configure failure, but not a later build failure. * src/util/virnetdevbridge.c: Include pre-req header. * configure.ac (AC_CHECK_HEADERS): Prefer standard in.h over non-standard ip6.h. (cherry picked from commit 1bf661ca)
-
由 Cole Robinson 提交于
I got this scary warning during ./configure on rawhide: checking linux/if_bridge.h usability... no checking linux/if_bridge.h presence... yes configure: WARNING: linux/if_bridge.h: present but cannot be compiled configure: WARNING: linux/if_bridge.h: check for missing prerequisite headers? configure: WARNING: linux/if_bridge.h: see the Autoconf documentation configure: WARNING: linux/if_bridge.h: section "Present But Cannot Be Compiled" configure: WARNING: linux/if_bridge.h: proceeding with the compiler's result configure: WARNING: ## ------------------------------------- ## configure: WARNING: ## Report this to libvir-list@redhat.com ## configure: WARNING: ## ------------------------------------- ## checking for linux/if_bridge.h... no * configure.ac (AC_CHECK_HEADERS): Provide struct in6_addr, since linux/if_bridge.h uses it without declaring it. (cherry picked from commit c308a9ae) (cherry picked from commit 7ae53f15)
-