17 Aug, 2017

1 commit

  • There's a bug which passes the output buffer size as MAX_IP_ADDR_SIZE,
    when converting the adapter_id field to UTF16. This is much larger than
    the actual size (MAX_ADAPTER_ID_SIZE). Fix this by passing the proper
    size.

    Fortunately, the translation is limited by the length of the input. This
    explains why we haven't seen output buffer overflow conditions.

    Signed-off-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Alex Ng
     

18 May, 2017

1 commit

  • The host may send multiple negotiation packets
    (due to timeout) before the KVP user-mode daemon
    is connected. KVP user-mode daemon is connected.
    We need to defer processing those packets
    until the daemon is negotiated and connected.
    It's okay for guest to respond
    to all negotiation packets.

    In addition, the host may send multiple staged
    KVP requests as soon as negotiation is done.
    We need to properly process those packets using one
    tasklet for exclusive access to ring buffer.

    This patch is based on the work of
    Nick Meier .

    Signed-off-by: Long Li
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Long Li
     

27 Mar, 2017

1 commit


17 Mar, 2017

2 commits


16 Mar, 2017

1 commit

  • Waiting for release_event in all three drivers introduced issues on release
    as on_reset() hook is not always called. E.g. if the device was never
    opened we will never get the completion.

    Move the waiting code to hvutil_transport_destroy() and make sure it is
    only called when the device is open. hvt->lock serialization should
    guarantee the absence of races.

    Fixes: 5a66fecbf6aa ("Drivers: hv: util: kvp: Fix a rescind processing issue")
    Fixes: 20951c7535b5 ("Drivers: hv: util: Fcopy: Fix a rescind processing issue")
    Fixes: d77044d142e9 ("Drivers: hv: util: Backup: Fix a rescind processing issue")

    Reported-by: Dexuan Cui
    Tested-by: Dexuan Cui
    Signed-off-by: Vitaly Kuznetsov
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     

31 Jan, 2017

2 commits

  • Log the negotiated IC versions.

    Signed-off-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Alex Ng
     
  • Previously, we were assuming that each IC protocol version was tied to a
    specific host version. For example, some Windows 10 preview hosts only
    support v3 TimeSync even though driver assumes v4 is supported by all
    Windows 10 hosts.

    The guest will stop trying to negotiate even though older supported
    versions may still be offered by the host.

    Make IC version negotiation more robust by going through all versions
    that are supported by the guest.

    Fixes: 3da0401b4d0e ("Drivers: hv: utils: Fix the mapping between host
    version and protocol to use")

    Reported-by: Rolf Neugebauer
    Signed-off-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Alex Ng
     

11 Jan, 2017

1 commit

  • KVP may use a char device to support the communication between
    the user level daemon and the driver. When the KVP channel is rescinded
    we need to make sure that the char device is fully cleaned up before
    we can process a new KVP offer from the host. Implement this logic.

    Signed-off-by: K. Y. Srinivasan
    Cc:
    Signed-off-by: Greg Kroah-Hartman

    K. Y. Srinivasan
     

31 Aug, 2016

1 commit

  • 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. Hostguest 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: Barry Davis
    Signed-off-by: Vitaly Kuznetsov
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     

02 May, 2016

1 commit

  • 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: Vitaly Kuznetsov
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     

02 Mar, 2016

1 commit

  • Pass the channel information to the util drivers that need to defer
    reading the channel while they are processing a request. This would address
    the following issue reported by Vitaly:

    Commit 3cace4a61610 ("Drivers: hv: utils: run polling callback always in
    interrupt context") removed direct *_transaction.state = HVUTIL_READY
    assignments from *_handle_handshake() functions introducing the following
    race: if a userspace daemon connects before we get first non-negotiation
    request from the server hv_poll_channel() won't set transaction state to
    HVUTIL_READY as (!channel) condition will fail, we set it to non-NULL on
    the first real request from the server.

    Signed-off-by: K. Y. Srinivasan
    Reported-by: Vitaly Kuznetsov
    Signed-off-by: Greg Kroah-Hartman

    K. Y. Srinivasan
     

15 Dec, 2015

3 commits

  • 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: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    K. Y. Srinivasan
     
  • 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: Olaf Hering
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Olaf Hering
     
  • 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: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    K. Y. Srinivasan
     

05 Aug, 2015

1 commit

  • kzalloc() return value check was accidentally lost in 11bc3a5fa91f:
    "Drivers: hv: kvp: convert to hv_utils_transport" commit.

    We don't need to reset kvp_transaction.state here as we have the
    kvp_timeout_func() timeout function and in case we're in OOM situation
    it is preferable to wait.

    Reported-by: Dan Carpenter
    Signed-off-by: Vitaly Kuznetsov
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     

25 May, 2015

7 commits

  • Unify driver registration reporting and move it to debug level as normally daemons write to syslog themselves
    and these kernel messages are useless.

    Signed-off-by: Vitaly Kuznetsov
    Tested-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     
  • Convert to hv_utils_transport to support both netlink and /dev/vmbus/hv_kvp communication methods.

    Signed-off-by: Vitaly Kuznetsov
    Tested-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     
  • Switch to using the hvutil_device_state state machine from using 2 different state variables: kvp_transaction.active and
    in_hand_shake.

    State transitions are:
    -> HVUTIL_DEVICE_INIT when driver loads or on device release
    -> HVUTIL_READY if the handshake was successful
    -> HVUTIL_HOSTMSG_RECEIVED when there is a non-negotiation message from the host
    -> HVUTIL_USERSPACE_REQ after we sent the message to the userspace daemon
    -> HVUTIL_USERSPACE_RECV after/if the userspace daemon has replied
    -> HVUTIL_READY after we respond to the host
    -> HVUTIL_DEVICE_DYING on driver unload

    In hv_kvp_onchannelcallback() process ICMSGTYPE_NEGOTIATE messages even when
    the userspace daemon is disconnected, otherwise we can make the host think
    we don't support KVP and disable the service completely.

    Unfortunately there is no good way we can figure out that the userspace daemon
    has died (unless we start treating all timeouts as such). In case the daemon
    restarts we skip the negotiation procedure (so the daemon is supposed to has
    the same version). This behavior is unchanged from in_handshake approach.

    Signed-off-by: Vitaly Kuznetsov
    Tested-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     
  • 'kvp_work' (and kvp_work_func) is a misnomer as it sounds like we expect
    this useful work to happen and in reality it is just an emergency escape when
    timeout happens.

    Signed-off-by: Vitaly Kuznetsov
    Tested-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     
  • Move poll_channel() to hyperv_vmbus.h and make it inline and rename it to hv_poll_channel() so it can be reused
    in other hv_util modules.

    Signed-off-by: Vitaly Kuznetsov
    Tested-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     
  • We set kvp_context when we want to postpone receiving a packet from vmbus due
    to the previous transaction being unfinished. We, however, never reset this
    state, all consequent kvp_respond_to_host() calls will result in poll_channel()
    calling hv_kvp_onchannelcallback(). This doesn't cause real issues as:
    1) Host is supposed to serialize transactions as well
    2) If no message is pending vmbus_recvpacket() will return 0 recvlen.
    This is just a cleanup.

    Signed-off-by: Vitaly Kuznetsov
    Tested-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     
  • These declarations are internal to hv_util module and hv_fcopy_* declarations
    already reside there.

    Signed-off-by: Vitaly Kuznetsov
    Tested-by: Alex Ng
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     

27 Nov, 2014

1 commit

  • 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: Vitaly Kuznetsov
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     

10 Jul, 2014

1 commit


08 Feb, 2014

1 commit


27 Sep, 2013

1 commit

  • The current code does not correctly negotiate the version numbers for the util
    driver when hosted on earlier hosts. The version numbers presented by this
    driver were not compatible with the version numbers supported by Windows Server
    2008. Fix this problem.

    I would like to thank Olaf Hering (ohering@suse.com) for identifying the problem.

    Reported-by: Olaf Hering
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    K. Y. Srinivasan
     

02 Aug, 2013

1 commit

  • 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: Olaf Hering
    Acked-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Olaf Hering
     

27 Jul, 2013

1 commit


06 Sep, 2012

1 commit

  • This is part of the IP injection protocol in that the host expects this field
    to reflect what addresses (address families) are currently bound to the
    interface. The KVP daemon is currently collecting this information and sending
    it to the kernel component. I had overlooked copying this and sending it
    back to the host. This patch addresses this issue.

    Signed-off-by: K. Y. Srinivasan
    Reviewed-by: Haiyang Zhang
    Signed-off-by: Greg Kroah-Hartman

    K. Y. Srinivasan
     

17 Aug, 2012

2 commits


14 May, 2012

1 commit


17 Mar, 2012

2 commits


14 Mar, 2012

1 commit


10 Feb, 2012

1 commit


03 Feb, 2012

1 commit


19 Nov, 2011

1 commit

  • 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: Alan Stern
    CC: Clemens Ladisch
    Signed-off-by: Greg Kroah-Hartman

    Alan Stern
     

11 Oct, 2011

1 commit