- 21 9月, 2013 3 次提交
-
-
由 Cole Robinson 提交于
-
由 Guannan Ren 提交于
Resolves:https://bugzilla.redhat.com/show_bug.cgi?id=923053 When cdrom is block type, the virsh change-media failed to insert source info because virsh uses "<source block='/dev/sdb'/>" while the correct name of the attribute for block disks is "dev". (cherry picked from commit 7729a168)
-
由 Gao feng 提交于
libvirt lxc will fail to start when selinux is disabled. error: Failed to start domain noroot error: internal error guest failed to start: PATH=/bin:/sbin TERM=linux container=lxc-libvirt container_uuid=b9873916-3516-c199-8112-1592ff694a9e LIBVIRT_LXC_UUID=b9873916-3516-c199-8112-1592ff694a9e LIBVIRT_LXC_NAME=noroot /bin/sh 2013-01-09 11:04:05.384+0000: 1: info : libvirt version: 1.0.1 2013-01-09 11:04:05.384+0000: 1: error : lxcContainerMountBasicFS:546 : Failed to mkdir /sys/fs/selinux: No such file or directory 2013-01-09 11:04:05.384+0000: 7536: info : libvirt version: 1.0.1 2013-01-09 11:04:05.384+0000: 7536: error : virLXCControllerRun:1466 : error receiving signal from container: Input/output error 2013-01-09 11:04:05.404+0000: 7536: error : virCommandWait:2287 : internal error Child process (ip link del veth1) unexpected exit status 1: Cannot find device "veth1" fix this problem by checking if selinuxfs is mounted in host before we try to create dir /sys/fs/selinux. Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com> (cherry picked from commit 8d63af22)
-
- 19 9月, 2013 1 次提交
-
-
由 Daniel P. Berrange 提交于
The 'stats' variable was not initialized to NULL, so if some early validation of the RPC call fails, it is possible to jump to the 'cleanup' label and VIR_FREE an uninitialized pointer. This is a security flaw, since the API can be called from a readonly connection which can trigger the validation checks. This was introduced in release v0.9.1 onwards by commit 158ba873 Author: Daniel P. Berrange <berrange@redhat.com> Date: Wed Apr 13 16:21:35 2011 +0100 Merge all returns paths from dispatcher into single path Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit e7f400a1) Conflicts: daemon/remote.c - context
-
- 18 9月, 2013 3 次提交
-
-
由 Daniel P. Berrange 提交于
With the existing pkcheck (pid, start time) tuple for identifying the process, there is a race condition, where a process can make a libvirt RPC call and in another thread exec a setuid application, causing it to change to effective UID 0. This in turn causes polkit to do its permission check based on the wrong UID. To address this, libvirt must get the UID the caller had at time of connect() (from SO_PEERCRED) and pass a (pid, start time, uid) triple to the pkcheck program. This fix requires that libvirt is re-built against a version of polkit that has the fix for its CVE-2013-4288, so that libvirt can see 'pkg-config --variable pkcheck_supports_uid polkit-gobject-1' Signed-off-by: NColin Walters <walters@redhat.com> Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 922b7fda) Signed-off-by: NEric Blake <eblake@redhat.com> Conflicts: configure.ac - context libvirt.spec.in - context of indentation src/access/viraccessdriverpolkit.c - not present on this branch
-
由 Daniel P. Berrange 提交于
Since PIDs can be reused, polkit prefers to be given a (PID,start time) pair. If given a PID on its own, it will attempt to lookup the start time in /proc/pid/stat, though this is subject to races. It is safer if the client app resolves the PID start time itself, because as long as the app has the client socket open, the client PID won't be reused. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> (cherry picked from commit 979e9c56) Signed-off-by: NEric Blake <eblake@redhat.com> Conflicts: src/libvirt_private.syms - not backported src/locking/lock_daemon.c - not backported src/rpc/virnetserverclient.c src/rpc/virnetsocket.c src/rpc/virnetsocket.h src/util/viridentity.h - not backported src/util/virprocess.c src/util/virprocess.h src/util/virstring.c src/util/virstring.h Most conflicts were contextual (this patch adds new functions, but upstream intermediate patches not backported here also added new features, and the resolution was picking out just the portions needed by this commit). virnetsocket.c also had slightly different locking semantics.
-
由 Matthias Bolte 提交于
Currently virNetSocketNew fails because virSetCloseExec fails as there is no proper implementation for it on Windows at the moment. Workaround this by pretending that setting close-on-exec on the fd works. This can be done because libvirt currently lacks the ability to create child processes on Windows anyway. So there is no point in failing to set a flag that isn't useful at the moment anyway. (cherry picked from commit fcfa4bfb)
-
- 16 9月, 2013 1 次提交
-
-
由 Liuji (Jeremy) 提交于
After freeing the bitmap pointer, it must set the pointer to NULL. This will avoid any other use of the freed memory of the bitmap pointer. https://bugzilla.redhat.com/show_bug.cgi?id=1006710Signed-off-by: NLiuji (Jeremy) <jeremy.liu@huawei.com> (cherry picked from commit ef5d51d4) Conflicts: src/conf/domain_conf.c
-
- 29 8月, 2013 1 次提交
-
-
由 Eric Blake 提交于
Commit 29fe5d74 (released in 1.1.1) introduced a latent problem for any caller of virSecurityManagerSetProcessLabel and where the domain already had a uid:gid label to be parsed. Such a setup would collect the list of supplementary groups during virSecurityManagerPreFork, but then ignores that information, and thus fails to call setgroups() to adjust the supplementary groups of the process. Upstream does not use virSecurityManagerSetProcessLabel for qemu (it uses virSecurityManagerSetChildProcessLabel instead), so this problem remained latent until backporting the initial commit into v0.10.2-maint (commit c061ff5e, released in 0.10.2.7), where virSecurityManagerSetChildProcessLabel has not been backported. As a result of using a different code path in the backport, attempts to start a qemu domain that runs as qemu:qemu will end up with supplementary groups unchanged from the libvirtd parent process, rather than the desired supplementary groups of the qemu user. This can lead to failure to start a domain (typical Fedora setup assigns user 107 'qemu' to both group 107 'qemu' and group 36 'kvm', so a disk image that is only readable under kvm group rights is locked out). Worse, it is a security hole (the qemu process will inherit supplemental group rights from the parent libvirtd process, which means it has access rights to files owned by group 0 even when such files should not normally be visible to user qemu). LXC does not use the DAC security driver, so it is not vulnerable at this time. Still, it is better to plug the latent hole on the master branch first, before cherry-picking it to the only vulnerable branch v0.10.2-maint. * src/security/security_dac.c (virSecurityDACGetIds): Always populate groups and ngroups, rather than only when no label is parsed. Signed-off-by: NEric Blake <eblake@redhat.com> (cherry picked from commit 745aa55f)
-
- 20 8月, 2013 2 次提交
-
-
由 Peter Krempa 提交于
The virBitmapParse function was calling virBitmapIsSet() function that requires the caller to check the bounds of the bitmap without checking them. This resulted into crashes when parsing a bitmap string that was exceeding the bounds used as argument. This patch refactors the function to use virBitmapSetBit without checking if the bit is set (this function does the checks internally) and then counts the bits in the bitmap afterwards (instead of keeping track while parsing the string). This patch also changes the "parse_error" label to a more common "error". The refactor should also get rid of the need to call sa_assert on the returned variable as the callpath should allow coverity to infer the possible return values. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=997367 Thanks to Alex Jia for tracking down the issue. This issue is introduced by commit 0fc89098. (cherry picked from commit 47b9127e) Conflicts: src/util/bitmap.c - context, coverity fix not backported
-
由 Eric Blake 提交于
Sometimes it's handy to know how many bits are set. * src/util/bitmap.h (virBitmapCountBits): New prototype. (virBitmapNextSetBit): Use correct type. * src/util/bitmap.c (virBitmapNextSetBit): Likewise. (virBitmapSetAll): Maintain invariant of clear tail bits. (virBitmapCountBits): New function. * src/libvirt_private.syms (bitmap.h): Export it. * tests/virbitmaptest.c (test2): Test it. (cherry picked from commit 0711c4b7)
-
- 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 2 次提交
-
-
由 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)
-