1. 15 11月, 2014 1 次提交
  2. 25 3月, 2014 1 次提交
  3. 20 3月, 2014 1 次提交
    • M
      virNetClientSetTLSSession: Restore original signal mask · 3d4b4f5a
      Michal Privoznik 提交于
      Currently, we use pthread_sigmask(SIG_BLOCK, ...) prior to calling
      poll(). This is okay, as we don't want poll() to be interrupted.
      However, then - immediately as we fall out from the poll() - we try to
      restore the original sigmask - again using SIG_BLOCK. But as the man
      page says, SIG_BLOCK adds signals to the signal mask:
      
      SIG_BLOCK
            The set of blocked signals is the union of the current set and the set argument.
      
      Therefore, when restoring the original mask, we need to completely
      overwrite the one we set earlier and hence we should be using:
      
      SIG_SETMASK
            The set of blocked signals is set to the argument set.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      3d4b4f5a
  4. 18 3月, 2014 3 次提交
  5. 10 3月, 2014 1 次提交
  6. 12 7月, 2013 1 次提交
    • P
      remote: Improve libssh2 password authentication · 273745b4
      Peter Krempa 提交于
      This patch enables the password authentication in the libssh2 connection
      driver. There are a few benefits to this step:
      
      1) Hosts with challenge response authentication will now be supported
      with the libssh2 connection driver.
      
      2) Credential for hosts can now be stored in the authentication
      credential config file
      273745b4
  7. 11 7月, 2013 1 次提交
  8. 10 7月, 2013 1 次提交
  9. 23 5月, 2013 1 次提交
  10. 21 5月, 2013 1 次提交
  11. 20 4月, 2013 1 次提交
    • E
      docs: fix usage of 'onto' · 1bf25ba2
      Eric Blake 提交于
      http://www.uhv.edu/ac/newsletters/writing/grammartip2009.07.01.htm
      (and several other sites) give hints that 'onto' is best used if
      you can also add 'up' just before it and still make sense. In many
      cases in the code base, we really want the two-word form, or even
      a simplification to just 'on' or 'to'.
      
      * docs/hacking.html.in: Use correct 'on to'.
      * python/libvirt-override.c: Likewise.
      * src/lxc/lxc_controller.c: Likewise.
      * src/util/virpci.c: Likewise.
      * daemon/THREADS.txt: Use simpler 'on'.
      * docs/formatdomain.html.in: Better usage.
      * docs/internals/rpc.html.in: Likewise.
      * src/conf/domain_event.c: Likewise.
      * src/rpc/virnetclient.c: Likewise.
      * tests/qemumonitortestutils.c: Likewise.
      * HACKING: Regenerate.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      1bf25ba2
  12. 27 3月, 2013 1 次提交
    • J
      rpc: Fix client crash when server drops connection · d8d4aa01
      Jiri Denemark 提交于
      Despite the comment stating virNetClientIncomingEvent handler should
      never be called with either client->haveTheBuck or client->wantClose
      set, there is a sequence of events that may lead to both booleans being
      true when virNetClientIncomingEvent is called. However, when that
      happens, we must not immediately close the socket as there are other
      threads waiting for the buck and they would cause SIGSEGV once they are
      woken up after the socket was closed. Another thing is we should clear
      all remaining calls in the queue after closing the socket.
      
      The situation that can lead to the crash involves three threads, one of
      them running event loop and the other two calling libvirt APIs. The
      event loop thread detects an event on client->sock and calls
      virNetClientIncomingEvent handler. But before the handler gets a chance
      to lock client, the other two threads (T1 and T2) start calling some
      APIs. T1 gets the buck and detects EOF on client->sock while processing
      its RPC call. Since T2 is waiting for its own call, T1 passes the buck
      on to it and unlocks client. But before T2 gets the signal, the event
      loop thread wakes up, does its job and closes client->sock. The crash
      happens when T2 actually wakes up and tries to do its job using a closed
      client->sock.
      d8d4aa01
  13. 14 3月, 2013 1 次提交
    • D
      Re-add DTrace probes on 'dispose' functions · ad9ea4a9
      Daniel P. Berrange 提交于
      When converting to virObject, the probes on the 'Free' functions
      were removed on the basis that there is a probe on virObjectFree
      that suffices. This puts a burden on people writing probe scripts
      to identify which object is being dispose. This adds back probes
      in the 'Dispose' functions and updates the rpc monitor systemtap
      example to use them
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      ad9ea4a9
  14. 21 2月, 2013 1 次提交
  15. 08 2月, 2013 1 次提交
  16. 23 1月, 2013 1 次提交
  17. 22 1月, 2013 1 次提交
  18. 18 1月, 2013 1 次提交
  19. 16 1月, 2013 2 次提交
  20. 14 1月, 2013 1 次提交
  21. 11 1月, 2013 1 次提交
  22. 09 1月, 2013 1 次提交
  23. 08 1月, 2013 1 次提交
  24. 21 12月, 2012 5 次提交
  25. 02 11月, 2012 1 次提交
  26. 21 9月, 2012 1 次提交
  27. 10 9月, 2012 1 次提交
    • C
      Fix unwanted closing of libvirt client connection · 164c03d3
      Christophe Fergeau 提交于
      e5a1bee0 introduced a regression in Boxes: when Boxes is left idle
      (it's still doing some libvirt calls in the background), the
      libvirt connection gets closed after a few minutes. What happens is
      that this code in virNetClientIOHandleOutput gets triggered:
      
      if (!thecall)
          return -1; /* Shouldn't happen, but you never know... */
      
      and after the changes in e5a1bee0, this causes the libvirt connection
      to be closed.
      
      Upon further investigation, what happens is that
      virNetClientIOHandleOutput is called from gvir_event_handle_dispatch
      in libvirt-glib, which is triggered because the client fd became
      writable. However, between the times gvir_event_handle_dispatch
      is called, and the time the client lock is grabbed and
      virNetClientIOHandleOutput is called, another thread runs and
      completes the current call. 'thecall' is then NULL when the first
      thread gets to run virNetClientIOHandleOutput.
      
      After describing this situation on IRC, danpb suggested this:
      
      11:37 < danpb> In that case I think the correct thing would be to change
                     'return -1' above to 'return 0' since that's not actually an
                     error - its a rare, but expected event
      
      which is what this patch is doing. I've tested it against master
      libvirt, and I didn't get disconnected in ~10 minutes while this
      happens in less than 5 minutes without this patch.
      164c03d3
  28. 27 8月, 2012 1 次提交
  29. 22 8月, 2012 1 次提交
    • P
      client: Change default location of known_hosts file for libssh2 layer · 225f2807
      Peter Krempa 提交于
      Unfortunately libssh2 doesn't support all types of host keys that can be
      saved in the known_hosts file. Also it does not report that parsing of
      the file failed. This results into truncated known_hosts files where the
      standard client stores keys also in other formats (eg.
      ecdsa-sha2-nistp256).
      
      This patch changes the default location of the known_hosts file into the
      libvirt private configuration directory, where it will be only written
      by the libssh2 layer itself. This prevents trashing user's known_host
      file.
      225f2807
  30. 21 8月, 2012 1 次提交
  31. 15 8月, 2012 1 次提交
  32. 09 8月, 2012 1 次提交
    • P
      Fix errno check, prevent spurious errors under heavy load · bfa74ebe
      Peter Feiner 提交于
      From man poll(2), poll does not set errno=EAGAIN on interrupt, however
      it does set errno=EINTR. Have libvirt retry on the appropriate errno.
      
      Under heavy load, a program of mine kept getting libvirt errors 'poll on
      socket failed: Interrupted system call'. The signals were SIGCHLD from
      processes forked by threads unrelated to those using libvirt.
      bfa74ebe
  33. 07 8月, 2012 1 次提交