1. 27 12月, 2019 2 次提交
  2. 13 12月, 2018 1 次提交
    • D
      Drivers: hv: vmbus: Offload the handling of channels to two workqueues · b02b86bc
      Dexuan Cui 提交于
      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 8195b139.
      
      Fixes: 8195b139 ("hv_netvsc: fix deadlock on hotplug")
      Cc: stable@vger.kernel.org
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: NDexuan Cui <decui@microsoft.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b02b86bc
  3. 02 8月, 2018 1 次提交
    • D
      Drivers: hv: vmbus: Reset the channel callback in vmbus_onoffer_rescind() · d3b26dd7
      Dexuan Cui 提交于
      Before setting channel->rescind in vmbus_rescind_cleanup(), we should make
      sure the channel callback won't run any more, otherwise a high-level
      driver like pci_hyperv, which may be infinitely waiting for the host VSP's
      response and notices the channel has been rescinded, can't safely give
      up: e.g., in hv_pci_protocol_negotiation() -> wait_for_response(), it's
      unsafe to exit from wait_for_response() and proceed with the on-stack
      variable "comp_pkt" popped. The issue was originally spotted by
      Michael Kelley <mikelley@microsoft.com>.
      
      In vmbus_close_internal(), the patch also minimizes the range protected by
      disabling/enabling channel->callback_event: we don't really need that for
      the whole function.
      Signed-off-by: NDexuan Cui <decui@microsoft.com>
      Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
      Cc: stable@vger.kernel.org
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: Michael Kelley <mikelley@microsoft.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d3b26dd7
  4. 03 7月, 2018 1 次提交
  5. 14 5月, 2018 1 次提交
    • D
      Drivers: hv: vmbus: enable VMBus protocol version 5.0 · ae20b254
      Dexuan Cui 提交于
      With VMBus protocol 5.0, we're able to better support new features, e.g.
      running two or more VMBus drivers simultaneously in a single VM -- note:
      we can't simply load the current VMBus driver twice, instead, a secondary
      VMBus driver must be implemented.
      
      This patch adds the support for the new VMBus protocol, which is available
      on new Windows hosts, by:
      
      1) We still use SINT2 for compatibility;
      2) We must use Connection ID 4 for the Initiate Contact Message, and for
      subsequent messages, we must use the Message Connection ID field in
      the host-returned VersionResponse Message.
      
      Notes for developers of the secondary VMBus driver:
      1) Must use VMBus protocol 5.0 as well;
      2) Must use a different SINT number that is not in use.
      3) Must use Connection ID 4 for the Initiate Contact Message, and for
      subsequent messages, must use the Message Connection ID field in
      the host-returned VersionResponse Message.
      4) It's possible that the primary VMBus driver using protocol version 4.0
      can work with a secondary VMBus driver using protocol version 5.0, but it's
      recommended that both should use 5.0 for new Hyper-V features in the future.
      Signed-off-by: NDexuan Cui <decui@microsoft.com>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Michael Kelley <mikelley@microsoft.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ae20b254
  6. 19 4月, 2018 1 次提交
  7. 29 3月, 2018 1 次提交
  8. 07 3月, 2018 1 次提交
  9. 03 12月, 2017 1 次提交
  10. 28 11月, 2017 1 次提交
  11. 31 10月, 2017 1 次提交
  12. 04 10月, 2017 2 次提交
  13. 17 8月, 2017 4 次提交
  14. 10 8月, 2017 3 次提交
  15. 17 7月, 2017 3 次提交
  16. 13 6月, 2017 1 次提交
  17. 17 3月, 2017 3 次提交
  18. 16 3月, 2017 2 次提交
    • D
      vmbus: remove hv_event_tasklet_disable/enable · dad72a1d
      Dexuan Cui 提交于
      With the recent introduction of per-channel tasklet, we need to update
      the way we handle the 3 concurrency issues:
      
      1. hv_process_channel_removal -> percpu_channel_deq vs.
         vmbus_chan_sched -> list_for_each_entry(..., percpu_list);
      
      2. vmbus_process_offer -> percpu_channel_enq/deq vs. vmbus_chan_sched.
      
      3. vmbus_close_internal vs. the per-channel tasklet vmbus_on_event;
      
      The first 2 issues can be handled by Stephen's recent patch
      "vmbus: use rcu for per-cpu channel list", and the third issue
      can be handled by calling tasklet_disable in vmbus_close_internal here.
      
      We don't need the original hv_event_tasklet_disable/enable since we
      now use per-channel tasklet instead of the previous per-CPU tasklet,
      and actually we must remove them due to the side effect now:
      vmbus_process_offer -> hv_event_tasklet_enable -> tasklet_schedule will
      start the per-channel callback prematurely, cauing NULL dereferencing
      (the channel may haven't been properly configured to run the callback yet).
      
      Fixes: 631e63a9 ("vmbus: change to per channel tasklet")
      Signed-off-by: NDexuan Cui <decui@microsoft.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Haiyang Zhang <haiyangz@microsoft.com>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Tested-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dad72a1d
    • S
      vmbus: use rcu for per-cpu channel list · 8200f208
      Stephen Hemminger 提交于
      The per-cpu channel list is now referred to in the interrupt
      routine. This is mostly safe since the host will not normally generate
      an interrupt when channel is being deleted but if it did then there
      would be a use after free problem.
      
      To solve, this use RCU protection on ther per-cpu list.
      
      Fixes: 631e63a9 ("vmbus: change to per channel tasklet")
      Signed-off-by: NStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8200f208
  19. 07 3月, 2017 1 次提交
  20. 15 2月, 2017 6 次提交
  21. 10 2月, 2017 2 次提交
  22. 31 1月, 2017 1 次提交