1. 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
  2. 10 Mar, 2017 1 commit
  3. 14 Feb, 2017 2 commits
  4. 10 Feb, 2017 3 commits
  5. 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
  6. 07 Nov, 2016 3 commits
  7. 02 Sep, 2016 2 commits
  8. 31 Aug, 2016 6 commits
  9. 08 Feb, 2016 3 commits
  10. 15 Dec, 2015 6 commits
  11. 05 Aug, 2015 1 commit
  12. 12 Jun, 2015 1 commit
  13. 24 May, 2015 1 commit
  14. 25 Mar, 2015 3 commits
  15. 02 Mar, 2015 4 commits