1. 17 Jul, 2017 1 commit
    • Stephen Hemminger's avatar
      vmbus: re-enable channel tasklet · 6463a457
      Stephen Hemminger authored
      This problem shows up in 4.11 when netvsc driver is removed and reloaded.
      The problem is that the channel is closed during module removal and the
      tasklet for processing responses is disabled. When module is reloaded
      the channel is reopened but the tasklet is marked as disabled.
      The fix is to re-enable tasklet at the end of close which gets it back
      to the initial state.
      
      The issue is less urgent in 4.12 since network driver now uses NAPI
      and not the tasklet; and other VMBUS devices are rarely unloaded/reloaded.
      
      Fixes: dad72a1d
      
       ("vmbus: remove hv_event_tasklet_disable/enable")
      
      Signed-off-by: default avatarStephen Hemminger <sthemmin@microsoft.com>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6463a457
  2. 18 May, 2017 1 commit
    • K. Y. Srinivasan's avatar
      Drivers: hv: vmbus: Fix rescind handling · 54a66265
      K. Y. Srinivasan authored
      
      
      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 <decui@microsoft.com> and
      Long Li <longli@microsoft.com> for working with me on this patch.
      
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      54a66265
  3. 17 Mar, 2017 1 commit
  4. 16 Mar, 2017 2 commits
    • K. Y. Srinivasan's avatar
      Drivers: hv: vmbus: Don't leak memory when a channel is rescinded · 5e030d5c
      K. Y. Srinivasan authored
      When we close a channel that has been rescinded, we will leak memory since
      vmbus_teardown_gpadl() returns an error. Fix this so that we can properly
      cleanup the memory allocated to the ring buffers.
      
      Fixes: ccb61f8a
      
       ("Drivers: hv: vmbus: Fix a rescind handling bug")
      
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5e030d5c
    • Dexuan Cui's avatar
      vmbus: remove hv_event_tasklet_disable/enable · dad72a1d
      Dexuan Cui authored
      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: default avatarDexuan 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: 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>
      dad72a1d
  5. 10 Mar, 2017 1 commit
  6. 14 Feb, 2017 2 commits
  7. 10 Feb, 2017 3 commits
  8. 10 Jan, 2017 2 commits
    • K. Y. Srinivasan's avatar
      Drivers: hv: vmbus: Fix a rescind handling bug · ccb61f8a
      K. Y. Srinivasan authored
      
      
      The host can rescind a channel that has been offered to the
      guest and once the channel is rescinded, the host does not
      respond to any requests on that channel. Deal with the case where
      the guest may be blocked waiting for a response from the host.
      
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ccb61f8a
    • Vitaly Kuznetsov's avatar
      Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg() · c0bb0392
      Vitaly Kuznetsov authored
      
      
      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: default avatarVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0bb0392
  9. 07 Nov, 2016 3 commits
  10. 02 Sep, 2016 2 commits
  11. 31 Aug, 2016 6 commits
  12. 08 Feb, 2016 3 commits
  13. 15 Dec, 2015 6 commits
  14. 05 Aug, 2015 1 commit
  15. 12 Jun, 2015 1 commit
  16. 24 May, 2015 1 commit
  17. 25 Mar, 2015 3 commits
  18. 02 Mar, 2015 1 commit