13 Dec, 2018

1 commit

  • commit 37c2578c0c40e286bc0d30bdc05290b2058cf66e upstream.

    vmbus_process_offer() mustn't call channel->sc_creation_callback()
    directly for sub-channels, because sc_creation_callback() ->
    vmbus_open() may never get the host's response to the
    OPEN_CHANNEL message (the host may rescind a channel at any time,
    e.g. in the case of hot removing a NIC), and vmbus_onoffer_rescind()
    may not wake up the vmbus_open() as it's blocked due to a non-zero
    vmbus_connection.offer_in_progress, and finally we have a deadlock.

    The above is also true for primary channels, if the related device
    drivers use sync probing mode by default.

    And, usually the handling of primary channels and sub-channels can
    depend on each other, so we should offload them to different
    workqueues to avoid possible deadlock, e.g. in sync-probing mode,
    NIC1's netvsc_subchan_work() can race with NIC2's netvsc_probe() ->
    rtnl_lock(), and causes deadlock: the former gets the rtnl_lock
    and waits for all the sub-channels to appear, but the latter
    can't get the rtnl_lock and this blocks the handling of sub-channels.

    The patch can fix the multiple-NIC deadlock described above for
    v3.x kernels (e.g. RHEL 7.x) which don't support async-probing
    of devices, and v4.4, v4.9, v4.14 and v4.18 which support async-probing
    but don't enable async-probing for Hyper-V drivers (yet).

    The patch can also fix the hang issue in sub-channel's handling described
    above for all versions of kernels, including v4.19 and v4.20-rc4.

    So actually the patch should be applied to all the existing kernels,
    not only the kernels that have 8195b1396ec8.

    Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
    Cc: stable@vger.kernel.org
    Cc: Stephen Hemminger
    Cc: K. Y. Srinivasan
    Cc: Haiyang Zhang
    Signed-off-by: Dexuan Cui
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Dexuan Cui
     

10 Aug, 2017

1 commit

  • To support implementing remote TLB flushing on Hyper-V with a hypercall
    we need to make vp_index available outside of vmbus module. Rename and
    globalize.

    Signed-off-by: Vitaly Kuznetsov
    Reviewed-by: Andy Shevchenko
    Reviewed-by: Stephen Hemminger
    Cc: Andy Lutomirski
    Cc: Haiyang Zhang
    Cc: Jork Loeser
    Cc: K. Y. Srinivasan
    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Simon Xiao
    Cc: Steven Rostedt
    Cc: Thomas Gleixner
    Cc: devel@linuxdriverproject.org
    Link: http://lkml.kernel.org/r/20170802160921.21791-7-vkuznets@redhat.com
    Signed-off-by: Ingo Molnar

    Vitaly Kuznetsov
     

18 May, 2017

2 commits

  • Fix the rescind handling. This patch addresses the following rescind
    scenario that is currently not handled correctly:

    If a rescind were to be received while the offer is still being
    peocessed, we will be blocked indefinitely since the rescind message
    is handled on the same work element as the offer message. Fix this
    issue.

    I would like to thank Dexuan Cui and
    Long Li for working with me on this patch.

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

    K. Y. Srinivasan
     
  • The current code unconditionally sends an IPI. If we are running on the
    correct CPU and are in interrupt level, we don't need an IPI.
    Make this adjustment.

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

    K. Y. Srinivasan
     

17 Mar, 2017

3 commits


15 Feb, 2017

5 commits


10 Feb, 2017

2 commits

  • The flag to cause notification of host is unused after
    commit a01a291a282f7c2e ("Drivers: hv: vmbus: Base host signaling
    strictly on the ring state"). Therefore remove it from the ring
    buffer internal API.

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

    Stephen Hemminger
     
  • Use standard kernel operations for find first set bit to traverse
    the channel bit array. This has added benefit of speeding up
    lookup on 64 bit and because it uses find first set instruction.

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

    Stephen Hemminger
     

31 Jan, 2017

1 commit

  • We need to cleanup the hypercall page before doing kexec/kdump or the new
    kernel may crash if it tries to use it. Reuse the now-empty hv_cleanup
    function renaming it to hyperv_cleanup and moving to the arch specific
    code.

    Fixes: 8730046c1498 ("Drivers: hv vmbus: Move Hypercall page setup out of common code")
    Signed-off-by: Vitaly Kuznetsov
    Signed-off-by: K. Y. Srinivasan
    Signed-off-by: Greg Kroah-Hartman

    Vitaly Kuznetsov
     

20 Jan, 2017

5 commits


19 Jan, 2017

3 commits


11 Jan, 2017

2 commits

  • To make it possible to online/offline CPUs switch to cpuhp infrastructure
    for doing hv_synic_init()/hv_synic_cleanup().

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

    Vitaly Kuznetsov
     
  • DoS protection conditions were altered in WS2016 and now it's easy to get
    -EAGAIN returned from vmbus_post_msg() (e.g. when we try changing MTU on a
    netvsc device in a loop). All vmbus_post_msg() callers don't retry the
    operation and we usually end up with a non-functional device or crash.

    While host's DoS protection conditions are unknown to me my tests show that
    it can take up to 10 seconds before the message is sent so doing udelay()
    is not an option, we really need to sleep. Almost all vmbus_post_msg()
    callers are ready to sleep but there is one special case:
    vmbus_initiate_unload() which can be called from interrupt/NMI context and
    we can't sleep there. I'm also not sure about the lonely
    vmbus_send_tl_connect_request() which has no in-tree users but its external
    users are most likely waiting for the host to reply so sleeping there is
    also appropriate.

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

    Vitaly Kuznetsov
     

07 Nov, 2016

3 commits


02 Sep, 2016

1 commit

  • Make it possible to always use a single memcpy() or to provide a direct
    link to a packet on the ring buffer by creating virtual mapping for two
    copies of the ring buffer with vmap(). Utilize currently empty
    hv_ringbuffer_cleanup() to do the unmap.

    While on it, replace sizeof(struct hv_ring_buffer) check
    in hv_ringbuffer_init() with BUILD_BUG_ON() as it is a compile time check.

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

    Vitaly Kuznetsov
     

31 Aug, 2016

2 commits

  • For synthetic NIC channels, enable explicit signaling policy as netvsc wants to
    explicitly control when the host is to be signaled.

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

    K. Y. Srinivasan
     
  • When we crash from NMI context (e.g. after NMI injection from host when
    'sysctl -w kernel.unknown_nmi_panic=1' is set) we hit

    kernel BUG at mm/vmalloc.c:1530!

    as vfree() is denied. While the issue could be solved with in_nmi() check
    instead I opted for skipping vfree on all sorts of crashes to reduce the
    amount of work which can cause consequent crashes. We don't really need to
    free anything on crash.

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

    Vitaly Kuznetsov
     

02 May, 2016

2 commits

  • Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
    delivered to the CPU which was used for initial contact or to CPU0
    depending on host version. vmbus_wait_for_unload() doesn't account for
    the fact that in case we're crashing on some other CPU we won't get the
    CHANNELMSG_UNLOAD_RESPONSE message and our wait on the current CPU will
    never end.

    Do the following:
    1) Check for completion_done() in the loop. In case interrupt handler is
    still alive we'll get the confirmation we need.

    2) Read message pages for all CPUs message page as we're unsure where
    CHANNELMSG_UNLOAD_RESPONSE is going to be delivered to. We can race with
    still-alive interrupt handler doing the same, add cmpxchg() to
    vmbus_signal_eom() to not lose CHANNELMSG_UNLOAD_RESPONSE message.

    3) Cleanup message pages on all CPUs. This is required (at least for the
    current CPU as we're clearing CPU0 messages now but we may want to bring
    up additional CPUs on crash) as new messages won't be delivered till we
    consume what's pending. On boot we'll place message pages somewhere else
    and we won't be able to read stale messages.

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

    Vitaly Kuznetsov
     
  • 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
     

01 May, 2016

1 commit


18 Mar, 2016

1 commit

  • Pull char/misc updates from Greg KH:
    "Here is the big char/misc driver update for 4.6-rc1.

    The majority of the patches here is hwtracing and some new mic
    drivers, but there's a lot of other driver updates as well. Full
    details in the shortlog.

    All have been in linux-next for a while with no reported issues"

    * tag 'char-misc-4.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (238 commits)
    goldfish: Fix build error of missing ioremap on UM
    nvmem: mediatek: Fix later provider initialization
    nvmem: imx-ocotp: Fix return value of imx_ocotp_read
    nvmem: Fix dependencies for !HAS_IOMEM archs
    char: genrtc: replace blacklist with whitelist
    drivers/hwtracing: make coresight-etm-perf.c explicitly non-modular
    drivers: char: mem: fix IS_ERROR_VALUE usage
    char: xillybus: Fix internal data structure initialization
    pch_phub: return -ENODATA if ROM can't be mapped
    Drivers: hv: vmbus: Support kexec on ws2012 r2 and above
    Drivers: hv: vmbus: Support handling messages on multiple CPUs
    Drivers: hv: utils: Remove util transport handler from list if registration fails
    Drivers: hv: util: Pass the channel information during the init call
    Drivers: hv: vmbus: avoid unneeded compiler optimizations in vmbus_wait_for_unload()
    Drivers: hv: vmbus: remove code duplication in message handling
    Drivers: hv: vmbus: avoid wait_for_completion() on crash
    Drivers: hv: vmbus: don't loose HVMSG_TIMER_EXPIRED messages
    misc: at24: replace memory_accessor with nvmem_device_read
    eeprom: 93xx46: extend driver to plug into the NVMEM framework
    eeprom: at25: extend driver to plug into the NVMEM framework
    ...

    Linus Torvalds
     

02 Mar, 2016

3 commits


17 Feb, 2016

1 commit

  • VMBus hypercall codes inside Hyper-V UAPI header will
    be used by QEMU to implement VMBus host devices support.

    Signed-off-by: Andrey Smetanin
    Acked-by: K. Y. Srinivasan
    Reviewed-by: Roman Kagan
    CC: Gleb Natapov
    CC: Paolo Bonzini
    CC: Joerg Roedel
    CC: "K. Y. Srinivasan"
    CC: Haiyang Zhang
    CC: Roman Kagan
    CC: Denis V. Lunev
    CC: qemu-devel@nongnu.org
    [Do not rename the constant at the same time as moving it, as that
    would cause semantic conflicts with the Hyper-V tree. - Paolo]
    Signed-off-by: Paolo Bonzini

    Andrey Smetanin
     

08 Feb, 2016

1 commit