1. 17 1月, 2014 2 次提交
  2. 16 1月, 2014 8 次提交
    • J
      Really don't crash if a connection closes early · 99f8d97a
      Jiri Denemark 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1047577
      
      When writing commit 173c2914, I missed the fact virNetServerClientClose
      unlocks the client object before actually clearing client->sock and thus
      it is possible to hit a window when client->keepalive is NULL while
      client->sock is not NULL. I was thinking client->sock == NULL was a
      better check for a closed connection but apparently we have to go with
      client->keepalive == NULL to actually fix the crash.
      Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      (cherry picked from commit 066c8ef6)
      99f8d97a
    • J
      Don't crash if a connection closes early · c4d275c9
      Jiri Denemark 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1047577
      
      When a client closes its connection to libvirtd early during
      virConnectOpen, more specifically just after making
      REMOTE_PROC_CONNECT_SUPPORTS_FEATURE call to check if
      VIR_DRV_FEATURE_PROGRAM_KEEPALIVE is supported without even waiting for
      the result, libvirtd may crash due to a race in keep-alive
      initialization. Once receiving the REMOTE_PROC_CONNECT_SUPPORTS_FEATURE
      call, the daemon's event loop delegates it to a worker thread. In case
      the event loop detects EOF on the connection and calls
      virNetServerClientClose before the worker thread starts to handle
      REMOTE_PROC_CONNECT_SUPPORTS_FEATURE call, client->keepalive will be
      disposed by the time virNetServerClientStartKeepAlive gets called from
      remoteDispatchConnectSupportsFeature. Because the flow is common for
      both authenticated and read-only connections, even unprivileged clients
      may cause the daemon to crash.
      
      To avoid the crash, virNetServerClientStartKeepAlive needs to check if
      the connection is still open before starting keep-alive protocol.
      
      Every libvirt release since 0.9.8 is affected by this bug.
      
      (cherry picked from commit 173c2914)
      c4d275c9
    • J
      qemu: Fix job usage in virDomainGetBlockIoTune · dee5fc75
      Jiri Denemark 提交于
      CVE-2013-6458
      
      Every API that is going to begin a job should do that before fetching
      data from vm->def.
      
      (cherry picked from commit 3b564259)
      dee5fc75
    • J
      qemu: Fix job usage in qemuDomainBlockCopy · 0135324b
      Jiri Denemark 提交于
      Every API that is going to begin a job should do that before fetching
      data from vm->def.
      
      (cherry picked from commit ff5f30b6)
      
      Conflicts:
      	src/qemu/qemu_driver.c - context
      0135324b
    • J
      qemu: Fix job usage in qemuDomainBlockJobImpl · 6cd87982
      Jiri Denemark 提交于
      CVE-2013-6458
      
      Every API that is going to begin a job should do that before fetching
      data from vm->def.
      
      (cherry picked from commit f93d2caa)
      6cd87982
    • J
      qemu: Avoid using stale data in virDomainGetBlockInfo · 92331918
      Jiri Denemark 提交于
      CVE-2013-6458
      
      Generally, every API that is going to begin a job should do that before
      fetching data from vm->def. However, qemuDomainGetBlockInfo does not
      know whether it will have to start a job or not before checking vm->def.
      To avoid using disk alias that might have been freed while we were
      waiting for a job, we use its copy. In case the disk was removed in the
      meantime, we will fail with "cannot find statistics for device '...'"
      error message.
      
      (cherry picked from commit b7992595)
      
      Conflicts:
      	src/qemu/qemu_driver.c - VIR_STRDUP not backported
      92331918
    • J
      qemu: Do not access stale data in virDomainBlockStats · c67b0de0
      Jiri Denemark 提交于
      CVE-2013-6458
      https://bugzilla.redhat.com/show_bug.cgi?id=1043069
      
      When virDomainDetachDeviceFlags is called concurrently to
      virDomainBlockStats: libvirtd may crash because qemuDomainBlockStats
      finds a disk in vm->def before getting a job on a domain and uses the
      disk pointer after getting the job. However, the domain in unlocked
      while waiting on a job condition and thus data behind the disk pointer
      may disappear. This happens when thread 1 runs
      virDomainDetachDeviceFlags and enters monitor to actually remove the
      disk. Then another thread starts running virDomainBlockStats, finds the
      disk in vm->def, and while it's waiting on the job condition (owned by
      the first thread), the first thread finishes the disk removal. When the
      second thread gets the job, the memory pointed to be the disk pointer is
      already gone.
      
      That said, every API that is going to begin a job should do that before
      fetching data from vm->def.
      
      (cherry picked from commit db86da5c)
      
      Conflicts:
      	src/qemu/qemu_driver.c - context: no ACLs
      c67b0de0
    • E
      tests: be more explicit on qcow2 versions in virstoragetest · 979d1bac
      Eric Blake 提交于
      While working on v1.0.5-maint (the branch in use on Fedora 19)
      with the host at Fedora 20, I got a failure in virstoragetest.
      I traced it to the fact that we were using qemu-img to create a
      qcow2 file, but qemu-img changed from creating v2 files by
      default in F19 to creating v3 files in F20.  Rather than leaving
      it up to qemu-img, it is better to write the test to force
      testing of BOTH file formats (better code coverage and all).
      
      This patch alone does not fix all the failures in v1.0.5-maint;
      for that, we must decide to either teach the older branch to
      understand v3 files, or to reject them outright as unsupported.
      But for upstream, making the test less dependent on changing
      qemu-img defaults is always a good thing.
      
      * tests/virstoragetest.c (testPrepImages): Simplify creation of
      raw file; check if qemu supports compat and if so use it.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      (cherry picked from commit 974e5914)
      
      Conflicts:
      	tests/virstoragetest.c - hardcode test to v2, since this branch doesn't handle v3 correctly
      979d1bac
  3. 09 1月, 2014 5 次提交
  4. 20 12月, 2013 2 次提交
    • M
      Fix crash in lxcDomainSetMemoryParameters · 2e35d287
      Martin Kletzander 提交于
      The function doesn't check whether the request is made for active or
      inactive domain.  Thus when the domain is not running it still tries
      accessing non-existing cgroups (priv->cgroup, which is NULL).
      
      I re-made the function in order for it to work the same way it's qemu
      counterpart does.
      
      Reproducer:
       1) Define an LXC domain
       2) Do 'virsh memtune <domain> --hard-limit 133T'
      
      Backtrace:
       Thread 6 (Thread 0x7fffec8c0700 (LWP 26826)):
       #0  0x00007ffff70edcc4 in virCgroupPathOfController (group=0x0, controller=3,
           key=0x7ffff75734bd "memory.limit_in_bytes", path=0x7fffec8bf718) at util/vircgroup.c:1764
       #1  0x00007ffff70e9206 in virCgroupSetValueStr (group=0x0, controller=3,
           key=0x7ffff75734bd "memory.limit_in_bytes", value=0x7fffe409f360 "1073741824")
           at util/vircgroup.c:669
       #2  0x00007ffff70e98b4 in virCgroupSetValueU64 (group=0x0, controller=3,
           key=0x7ffff75734bd "memory.limit_in_bytes", value=1073741824) at util/vircgroup.c:740
       #3  0x00007ffff70ee518 in virCgroupSetMemory (group=0x0, kb=1048576) at util/vircgroup.c:1904
       #4  0x00007ffff70ee675 in virCgroupSetMemoryHardLimit (group=0x0, kb=1048576)
           at util/vircgroup.c:1944
       #5  0x00005555557d54c8 in lxcDomainSetMemoryParameters (dom=0x7fffe40cc420,
           params=0x7fffe409f100, nparams=1, flags=0) at lxc/lxc_driver.c:774
       #6  0x00007ffff72c20f9 in virDomainSetMemoryParameters (domain=0x7fffe40cc420,
           params=0x7fffe409f100, nparams=1, flags=0) at libvirt.c:4051
       #7  0x000055555561365f in remoteDispatchDomainSetMemoryParameters (server=0x555555eb7e00,
           client=0x555555ec4b10, msg=0x555555eb94e0, rerr=0x7fffec8bfb70, args=0x7fffe40b8510)
           at remote_dispatch.h:7621
       #8  0x00005555556133fd in remoteDispatchDomainSetMemoryParametersHelper (server=0x555555eb7e00,
           client=0x555555ec4b10, msg=0x555555eb94e0, rerr=0x7fffec8bfb70, args=0x7fffe40b8510,
           ret=0x7fffe40b84f0) at remote_dispatch.h:7591
       #9  0x00007ffff73b293f in virNetServerProgramDispatchCall (prog=0x555555ec3ae0,
           server=0x555555eb7e00, client=0x555555ec4b10, msg=0x555555eb94e0)
           at rpc/virnetserverprogram.c:435
       #10 0x00007ffff73b207f in virNetServerProgramDispatch (prog=0x555555ec3ae0,
           server=0x555555eb7e00, client=0x555555ec4b10, msg=0x555555eb94e0)
           at rpc/virnetserverprogram.c:305
       #11 0x00007ffff73a4d2c in virNetServerProcessMsg (srv=0x555555eb7e00, client=0x555555ec4b10,
           prog=0x555555ec3ae0, msg=0x555555eb94e0) at rpc/virnetserver.c:165
       #12 0x00007ffff73a4e8d in virNetServerHandleJob (jobOpaque=0x555555ec3e30, opaque=0x555555eb7e00)
           at rpc/virnetserver.c:186
       #13 0x00007ffff7187f3f in virThreadPoolWorker (opaque=0x555555eb7ac0) at util/virthreadpool.c:144
       #14 0x00007ffff718733a in virThreadHelper (data=0x555555eb7890) at util/virthreadpthread.c:161
       #15 0x00007ffff468ed89 in start_thread (arg=0x7fffec8c0700) at pthread_create.c:308
       #16 0x00007ffff3da26bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      (cherry picked from commit 9faf3f29)
      
      Conflicts:
      	src/lxc/lxc_driver.c
      2e35d287
    • M
      CVE-2013-6436: fix crash in lxcDomainGetMemoryParameters · 218bd2e8
      Martin Kletzander 提交于
      The function doesn't check whether the request is made for active or
      inactive domain.  Thus when the domain is not running it still tries
      accessing non-existing cgroups (priv->cgroup, which is NULL).
      
      I re-made the function in order for it to work the same way it's qemu
      counterpart does.
      
      Reproducer:
       1) Define an LXC domain
       2) Do 'virsh memtune <domain>'
      
      Backtrace:
       Thread 6 (Thread 0x7fffec8c0700 (LWP 13387)):
       #0  0x00007ffff70edcc4 in virCgroupPathOfController (group=0x0, controller=3,
           key=0x7ffff75734bd "memory.limit_in_bytes", path=0x7fffec8bf750) at util/vircgroup.c:1764
       #1  0x00007ffff70e958c in virCgroupGetValueStr (group=0x0, controller=3,
           key=0x7ffff75734bd "memory.limit_in_bytes", value=0x7fffec8bf7c0) at util/vircgroup.c:705
       #2  0x00007ffff70e9d29 in virCgroupGetValueU64 (group=0x0, controller=3,
           key=0x7ffff75734bd "memory.limit_in_bytes", value=0x7fffec8bf810) at util/vircgroup.c:804
       #3  0x00007ffff70ee706 in virCgroupGetMemoryHardLimit (group=0x0, kb=0x7fffec8bf8a8)
           at util/vircgroup.c:1962
       #4  0x00005555557d590f in lxcDomainGetMemoryParameters (dom=0x7fffd40024a0,
           params=0x7fffd40027a0, nparams=0x7fffec8bfa24, flags=0) at lxc/lxc_driver.c:826
       #5  0x00007ffff72c28d3 in virDomainGetMemoryParameters (domain=0x7fffd40024a0,
           params=0x7fffd40027a0, nparams=0x7fffec8bfa24, flags=0) at libvirt.c:4137
       #6  0x000055555563714d in remoteDispatchDomainGetMemoryParameters (server=0x555555eb7e00,
           client=0x555555ebaef0, msg=0x555555ebb3e0, rerr=0x7fffec8bfb70, args=0x7fffd40024e0,
           ret=0x7fffd4002420) at remote.c:1895
       #7  0x00005555556052c4 in remoteDispatchDomainGetMemoryParametersHelper (server=0x555555eb7e00,
           client=0x555555ebaef0, msg=0x555555ebb3e0, rerr=0x7fffec8bfb70, args=0x7fffd40024e0,
           ret=0x7fffd4002420) at remote_dispatch.h:4050
       #8  0x00007ffff73b293f in virNetServerProgramDispatchCall (prog=0x555555ec3ae0,
           server=0x555555eb7e00, client=0x555555ebaef0, msg=0x555555ebb3e0)
           at rpc/virnetserverprogram.c:435
       #9  0x00007ffff73b207f in virNetServerProgramDispatch (prog=0x555555ec3ae0,
           server=0x555555eb7e00, client=0x555555ebaef0, msg=0x555555ebb3e0)
           at rpc/virnetserverprogram.c:305
       #10 0x00007ffff73a4d2c in virNetServerProcessMsg (srv=0x555555eb7e00, client=0x555555ebaef0,
           prog=0x555555ec3ae0, msg=0x555555ebb3e0) at rpc/virnetserver.c:165
       #11 0x00007ffff73a4e8d in virNetServerHandleJob (jobOpaque=0x555555ebc7e0, opaque=0x555555eb7e00)
           at rpc/virnetserver.c:186
       #12 0x00007ffff7187f3f in virThreadPoolWorker (opaque=0x555555eb7ac0) at util/virthreadpool.c:144
       #13 0x00007ffff718733a in virThreadHelper (data=0x555555eb7890) at util/virthreadpthread.c:161
       #14 0x00007ffff468ed89 in start_thread (arg=0x7fffec8c0700) at pthread_create.c:308
       #15 0x00007ffff3da26bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      (cherry picked from commit f8c1cb90)
      
      Conflicts:
      	src/lxc/lxc_driver.c
      218bd2e8
  5. 15 12月, 2013 4 次提交
    • C
      Prep for release 1.0.5.8 · 2d0a9b97
      Cole Robinson 提交于
      2d0a9b97
    • C
      Tie SASL callbacks lifecycle to virNetSessionSASLContext · 46a6015b
      Christophe Fergeau 提交于
      The array of sasl_callback_t callbacks which is passed to sasl_client_new()
      must be kept alive as long as the created sasl_conn_t object is alive as
      cyrus-sasl uses this structure internally for things like logging, so
      the memory used for callbacks must only be freed after sasl_dispose() has
      been called.
      
      During testing of successful SASL logins with
      virsh -c qemu+tls:///system list --all
      I've been getting invalid read reports from valgrind
      
      ==9237== Invalid read of size 8
      ==9237==    at 0x6E93B6F: _sasl_getcallback (common.c:1745)
      ==9237==    by 0x6E95430: _sasl_log (common.c:1850)
      ==9237==    by 0x16593D87: digestmd5_client_mech_dispose (digestmd5.c:4580)
      ==9237==    by 0x6E91653: client_dispose (client.c:332)
      ==9237==    by 0x6E9476A: sasl_dispose (common.c:851)
      ==9237==    by 0x4E225A1: virNetSASLSessionDispose (virnetsaslcontext.c:678)
      ==9237==    by 0x4CBC551: virObjectUnref (virobject.c:262)
      ==9237==    by 0x4E254D1: virNetSocketDispose (virnetsocket.c:1042)
      ==9237==    by 0x4CBC551: virObjectUnref (virobject.c:262)
      ==9237==    by 0x4E2701C: virNetSocketEventFree (virnetsocket.c:1794)
      ==9237==    by 0x4C965D3: virEventPollCleanupHandles (vireventpoll.c:583)
      ==9237==    by 0x4C96987: virEventPollRunOnce (vireventpoll.c:652)
      ==9237==    by 0x4C94730: virEventRunDefaultImpl (virevent.c:274)
      ==9237==    by 0x12C7BA: vshEventLoop (virsh.c:2407)
      ==9237==    by 0x4CD3D04: virThreadHelper (virthreadpthread.c:161)
      ==9237==    by 0x7DAEF32: start_thread (pthread_create.c:309)
      ==9237==    by 0x8C86EAC: clone (clone.S:111)
      ==9237==  Address 0xe2d61b0 is 0 bytes inside a block of size 168 free'd
      ==9237==    at 0x4A07577: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
      ==9237==    by 0x4C73827: virFree (viralloc.c:580)
      ==9237==    by 0x4DE4BC7: remoteAuthSASL (remote_driver.c:4219)
      ==9237==    by 0x4DE33D0: remoteAuthenticate (remote_driver.c:3639)
      ==9237==    by 0x4DDBFAA: doRemoteOpen (remote_driver.c:832)
      ==9237==    by 0x4DDC8DC: remoteConnectOpen (remote_driver.c:1031)
      ==9237==    by 0x4D8595F: do_open (libvirt.c:1239)
      ==9237==    by 0x4D863F3: virConnectOpenAuth (libvirt.c:1481)
      ==9237==    by 0x12762B: vshReconnect (virsh.c:337)
      ==9237==    by 0x12C9B0: vshInit (virsh.c:2470)
      ==9237==    by 0x12E9A5: main (virsh.c:3338)
      
      This commit changes virNetSASLSessionNewClient() to take ownership of the SASL
      callbacks. Then we can free them in virNetSASLSessionDispose() after the corresponding
      sasl_conn_t has been freed.
      
      (cherry picked from commit 13fdc6d6)
      46a6015b
    • J
      spec: Don't save/restore running VMs on libvirt-client update · 140485ab
      Jiri Denemark 提交于
      The previous attempt (commit d65e0e14) removed just one of two
      libvirt-guests restarts that happened on libvirt-client update. Let's
      remove the last one too :-)
      
      https://bugzilla.redhat.com/show_bug.cgi?id=962225Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
      (cherry picked from commit 604f79b3)
      140485ab
    • D
      Return right error code for baselineCPU · dba6ded8
      Don Dugger 提交于
      This Python interface code is returning a -1 on errors for the
      `baselineCPU' API.  Since this API is supposed to return a pointer
      the error return value should really be VIR_PY_NONE.
      
      NB:  I've checked all the other APIs in this file and this is the
      only pointer API that is returning -1.
      Signed-off-by: NDon Dugger <donald.d.dugger@intel.com>
      
      (crobinso: Upstream in libvirt-python.git)
      dba6ded8
  6. 22 11月, 2013 1 次提交
  7. 20 11月, 2013 3 次提交
  8. 18 11月, 2013 2 次提交
  9. 13 11月, 2013 1 次提交
  10. 07 11月, 2013 4 次提交
    • J
      spec: Explicitly require libgcrypt-devel · c75683da
      Jiri Denemark 提交于
      Our configure.ac says:
      
          Not all versions of gnutls include -lgcrypt, and so we add
          it explicitly for the calls to gcry_control/check_version
      
      Thus we cannot rely on gnutls-devel to bring grcypt-devel as a
      dependency.
      
      (cherry picked from commit 3b50a711)
      c75683da
    • C
      Prep for release 1.0.5.7 · 7fd01c6a
      Cole Robinson 提交于
      7fd01c6a
    • M
      qemuSetupMemoryCgroup: Handle hard_limit properly · 11253a09
      Michal Privoznik 提交于
      Since 16bcb3 we have a regression. The hard_limit is set
      unconditionally. By default the limit is zero. Hence, if user hasn't
      configured any, we set the zero in cgroup subsystem making the kernel
      kill the corresponding qemu process immediately. The proper fix is to
      set hard_limit iff user has configured any.
      
      (cherry picked from commit 94a24dd3)
      
      Conflicts:
      	src/qemu/qemu_cgroup.c
      11253a09
    • M
      qemu: Drop qemuDomainMemoryLimit · 9421fd00
      Michal Privoznik 提交于
      This function is to guess the correct limit for maximal memory
      usage by qemu for given domain. This can never be guessed
      correctly, not to mention all the pains and sleepless nights this
      code has caused. Once somebody discovers algorithm to solve the
      Halting Problem, we can compute the limit algorithmically. But
      till then, this code should never see the light of the release
      again.
      
      (cherry picked from commit 16bcb3b6)
      
      Conflicts:
      	src/qemu/qemu_cgroup.c
      	src/qemu/qemu_command.c
      	src/qemu/qemu_domain.c
      	src/qemu/qemu_domain.h
      	src/qemu/qemu_hotplug.c
      9421fd00
  11. 18 10月, 2013 2 次提交
    • Z
      remote: fix regression in event deregistration · 03ba101a
      Zhou Yimin 提交于
      Introduced by 7b87a3
      When I quit the process which only register VIR_DOMAIN_EVENT_ID_REBOOT,
      I got error like:
      "libvirt: XML-RPC error : internal error: domain event 0 not registered".
      Then I add the following code, it fixed.
      Signed-off-by: NZhou Yimin <zhouyimin@huawei.com>
      Signed-off-by: NEric Blake <eblake@redhat.com>
      (cherry picked from commit 9712c251)
      03ba101a
    • M
      virsh: Fix debugging · 99fa1ade
      Martin Kletzander 提交于
      Commit a0b6a36f "fixed" what abfff210 broke (URI precedence), but
      there was still one more thing missing to fix.  When using virsh
      parameters to setup debugging, those weren't honored, because at the
      time debugging was initializing, arguments weren't parsed yet.  To
      make ewerything work as expected, we need to initialize the debugging
      twice, once before debugging (so we can debug option parsing properly)
      and then again after these options are parsed.
      
      As a side effect, this patch also fixes a leak when virsh is ran with
      multiple '-l' parameters.
      Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
      (cherry picked from commit ac43da70)
      99fa1ade
  12. 15 10月, 2013 6 次提交
新手
引导
客服 返回
顶部