An error occurred fetching the project authors.
  1. 12 Mar, 2017 1 commit
  2. 31 Aug, 2016 1 commit
    • Vitaly Kuznetsov's avatar
      Drivers: hv: utils: fix a race on userspace daemons registration · e0fa3e5e
      Vitaly Kuznetsov authored
      Background: userspace daemons registration protocol for Hyper-V utilities
      drivers has two steps:
      1) daemon writes its own version to kernel
      2) kernel reads it and replies with module version
      at this point we consider the handshake procedure being completed and we
      do hv_poll_channel() transitioning the utility device to HVUTIL_READY
      state. At this point we're ready to handle messages from kernel.
      
      When hvutil_transport is in HVUTIL_TRANSPORT_CHARDEV mode we have a
      single buffer for outgoing message. hvutil_transport_send() puts to this
      buffer and till the buffer is cleared with hvt_op_read() returns -EFAULT
      to all consequent calls. Host<->guest protocol guarantees there is no more
      than one request at a time and we will not get new requests till we reply
      to the previous one so this single message buffer is enough.
      
      Now to the race. When we finish negotiation procedure and send kernel
      module version to userspace with hvutil_transport_send() it goes into the
      above mentioned buffer and if the daemon is slow enough to read it from
      there we can get a collision when a request from the host comes, we won't
      be able to put anything to the buffer so the request will be lost. To
      solve the issue we need to know when the negotiation is really done (when
      the version message is read by the daemon) and transition to HVUTIL_READY
      state after this happens. Implement a callback on read to support this.
      Old style netlink communication is not affected by the change, we don't
      really know when these messages are delivered but we don't have a single
      message buffer there.
      Reported-by: default avatarBarry Davis <barry_davis@stormagic.com>
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e0fa3e5e
  3. 01 May, 2016 1 commit
    • Vitaly Kuznetsov's avatar
      Drivers: hv: kvp: fix IP Failover · 4dbfc2e6
      Vitaly Kuznetsov authored
      Hyper-V VMs can be replicated to another hosts and there is a feature to
      set different IP for replicas, it is called 'Failover TCP/IP'. When
      such guest starts Hyper-V host sends it KVP_OP_SET_IP_INFO message as soon
      as we finish negotiation procedure. The problem is that it can happen (and
      it actually happens) before userspace daemon connects and we reply with
      HV_E_FAIL to the message. As there are no repetitions we fail to set the
      requested IP.
      
      Solve the issue by postponing our reply to the negotiation message till
      userspace daemon is connected. We can't wait too long as there is a
      host-side timeout (cca. 75 seconds) and if we fail to reply in this time
      frame the whole KVP service will become inactive. The solution is not
      ideal - if it takes userspace daemon more than 60 seconds to connect
      IP Failover will still fail but I don't see a solution with our current
      separation between kernel and userspace parts.
      
      Other two modules (VSS and FCOPY) don't require such delay, leave them
      untouched.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4dbfc2e6
  4. 02 Mar, 2016 1 commit
  5. 15 Dec, 2015 3 commits
    • K. Y. Srinivasan's avatar
      Drivers: hv: utils: Invoke the poll function after handshake · 2d0c3b5a
      K. Y. Srinivasan authored
      When the handshake with daemon is complete, we should poll the channel since
      during the handshake, we will not be processing any messages. This is a
      potential bug if the host is waiting for a response from the guest.
      I would like to thank Dexuan for pointing this out.
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2d0c3b5a
    • Olaf Hering's avatar
      Drivers: hv: utils: run polling callback always in interrupt context · 3cace4a6
      Olaf Hering authored
      All channel interrupts are bound to specific VCPUs in the guest
      at the point channel is created. While currently, we invoke the
      polling function on the correct CPU (the CPU to which the channel
      is bound to) in some cases we may run the polling function in
      a non-interrupt context. This  potentially can cause an issue as the
      polling function can be interrupted by the channel callback function.
      Fix the issue by running the polling function on the appropriate CPU
      at interrupt level. Additional details of the issue being addressed by
      this patch are given below:
      
      Currently hv_fcopy_onchannelcallback is called from interrupts and also
      via the ->write function of hv_utils. Since the used global variables to
      maintain state are not thread safe the state can get out of sync.
      This affects the variable state as well as the channel inbound buffer.
      
      As suggested by KY adjust hv_poll_channel to always run the given
      callback on the cpu which the channel is bound to. This avoids the need
      for locking because all the util services are single threaded and only
      one transaction is active at any given point in time.
      
      Additionally, remove the context variable, they will always be the same as
      recv_channel.
      Signed-off-by: default avatarOlaf Hering <olaf@aepfle.de>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3cace4a6
    • K. Y. Srinivasan's avatar
      Drivers: hv: util: Increase the timeout for util services · c0b200cf
      K. Y. Srinivasan authored
      Util services such as KVP and FCOPY need assistance from daemon's running
      in user space. Increase the timeout so we don't prematurely terminate
      the transaction in the kernel. Host sets up a 60 second timeout for
      all util driver transactions. The host will retry the transaction if it
      times out. Set the guest timeout at 30 seconds.
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0b200cf
  6. 05 Aug, 2015 1 commit
  7. 24 May, 2015 7 commits
  8. 27 Nov, 2014 1 commit
    • Vitaly Kuznetsov's avatar
      Drivers: hv: kvp,vss: Fast propagation of userspace communication failure · 8d9560eb
      Vitaly Kuznetsov authored
      If we fail to send a message to userspace daemon with cn_netlink_send()
      there is no need to wait for userspace to reply as it is not going to
      happen. This happens when kvp or vss daemon is stopped after a successful
      handshake. Report HV_E_FAIL immediately and cancel the timeout job so
      host won't receive two failures.
      Use pr_warn() for VSS and pr_debug() for KVP deliberately as VSS request
      are rare and result in a failed backup. KVP requests are much more frequent
      after a successful handshake so avoid flooding logs. It would be nice to
      have an ability to de-negotiate with the host in case userspace daemon gets
      disconnected so we won't receive new requests. But I'm not sure it is
      possible.
      Signed-off-by: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8d9560eb
  9. 09 Jul, 2014 1 commit
  10. 07 Feb, 2014 1 commit
  11. 26 Sep, 2013 1 commit
  12. 02 Aug, 2013 1 commit
    • Olaf Hering's avatar
      Drivers: hv: remove HV_DRV_VERSION · cfc25993
      Olaf Hering authored
      Remove HV_DRV_VERSION, it has no meaning for upstream drivers.
      
      Initially it was supposed to show the "Linux Integration Services"
      version, now it is not in sync anymore with the out-of-tree drivers
      available from the MSFT website.
      
      The only place where a version string is still required is the KVP
      command "IntegrationServicesVersion" which is handled by
      tools/hv/hv_kvp_daemon.c. To satisfy such KVP request from the host pass
      the current string to the daemon during KVP userland registration.
      Signed-off-by: default avatarOlaf Hering <olaf@aepfle.de>
      Acked-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cfc25993
  13. 26 Jul, 2013 1 commit
  14. 05 Sep, 2012 1 commit
  15. 17 Aug, 2012 1 commit
  16. 16 Aug, 2012 1 commit
  17. 14 May, 2012 1 commit
  18. 16 Mar, 2012 2 commits
  19. 13 Mar, 2012 1 commit
  20. 09 Feb, 2012 1 commit
  21. 02 Feb, 2012 1 commit
  22. 18 Nov, 2011 1 commit
    • Alan Stern's avatar
      NLS: improve UTF8 -> UTF16 string conversion routine · 0720a06a
      Alan Stern authored
      The utf8s_to_utf16s conversion routine needs to be improved.  Unlike
      its utf16s_to_utf8s sibling, it doesn't accept arguments specifying
      the maximum length of the output buffer or the endianness of its
      16-bit output.
      
      This patch (as1501) adds the two missing arguments, and adjusts the
      only two places in the kernel where the function is called.  A
      follow-on patch will add a third caller that does utilize the new
      capabilities.
      
      The two conversion routines are still annoyingly inconsistent in the
      way they handle invalid byte combinations.  But that's a subject for a
      different patch.
      Signed-off-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: Clemens Ladisch <clemens@ladisch.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      0720a06a
  23. 11 Oct, 2011 4 commits
  24. 20 Sep, 2011 2 commits
  25. 17 May, 2011 3 commits