1. 29 3月, 2018 1 次提交
  2. 04 11月, 2017 2 次提交
  3. 31 10月, 2017 1 次提交
  4. 10 8月, 2017 3 次提交
  5. 25 5月, 2017 1 次提交
  6. 18 5月, 2017 2 次提交
  7. 17 3月, 2017 1 次提交
  8. 15 2月, 2017 3 次提交
  9. 10 2月, 2017 1 次提交
  10. 20 1月, 2017 1 次提交
  11. 11 1月, 2017 1 次提交
    • V
      Drivers: hv: vmbus: Raise retry/wait limits in vmbus_post_msg() · c0bb0392
      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: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c0bb0392
  12. 06 12月, 2016 1 次提交
  13. 31 8月, 2016 1 次提交
  14. 01 5月, 2016 1 次提交
  15. 02 3月, 2016 2 次提交
  16. 08 2月, 2016 2 次提交
  17. 15 12月, 2015 2 次提交
  18. 01 6月, 2015 1 次提交
  19. 25 5月, 2015 1 次提交
  20. 03 4月, 2015 2 次提交
  21. 25 3月, 2015 1 次提交
  22. 02 3月, 2015 3 次提交
    • K
      Drivers: hv: vmbus: Get rid of some unnecessary messages · 37f492ce
      K. Y. Srinivasan 提交于
      Currently we log messages when either we are not able to map an ID to a
      channel or when the channel does not have a callback associated
      (in the channel interrupt handling path). These messages don't add
      any value, get rid of them.
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37f492ce
    • D
      hv: vmbus_post_msg: retry the hypercall on some transient errors · 89f9f679
      Dexuan Cui 提交于
      I got HV_STATUS_INVALID_CONNECTION_ID on Hyper-V 2008 R2 when keeping running
      "rmmod hv_netvsc; modprobe hv_netvsc; rmmod hv_utils; modprobe hv_utils"
      in a Linux guest. Looks the host has some kind of throttling mechanism if
      some kinds of hypercalls are sent too frequently.
      Without the patch, the driver can occasionally fail to load.
      
      Also let's retry HV_STATUS_INSUFFICIENT_MEMORY, though we didn't get it
      before.
      
      Removed 'case -ENOMEM', since the hypervisor doesn't return this.
      
      CC: "K. Y. Srinivasan" <kys@microsoft.com>
      Reviewed-by: NJason Wang <jasowang@redhat.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>
      89f9f679
    • V
      Drivers: hv: vmbus: teardown hv_vmbus_con workqueue and vmbus_connection pages on shutdown · 09a19628
      Vitaly Kuznetsov 提交于
      We need to destroy hv_vmbus_con on module shutdown, otherwise the following
      crash is sometimes observed:
      
      [   76.569845] hv_vmbus: Hyper-V Host Build:9600-6.3-17-0.17039; Vmbus version:3.0
      [   82.598859] BUG: unable to handle kernel paging request at ffffffffa0003480
      [   82.599287] IP: [<ffffffffa0003480>] 0xffffffffa0003480
      [   82.599287] PGD 1f34067 PUD 1f35063 PMD 3f72d067 PTE 0
      [   82.599287] Oops: 0010 [#1] SMP
      [   82.599287] Modules linked in: [last unloaded: hv_vmbus]
      [   82.599287] CPU: 0 PID: 26 Comm: kworker/0:1 Not tainted 3.19.0-rc5_bug923184+ #488
      [   82.599287] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v1.0 11/26/2012
      [   82.599287] Workqueue: hv_vmbus_con 0xffffffffa0003480
      [   82.599287] task: ffff88007b6ddfa0 ti: ffff88007f8f8000 task.ti: ffff88007f8f8000
      [   82.599287] RIP: 0010:[<ffffffffa0003480>]  [<ffffffffa0003480>] 0xffffffffa0003480
      [   82.599287] RSP: 0018:ffff88007f8fbe00  EFLAGS: 00010202
      ...
      
      To avoid memory leaks we need to free monitor_pages and int_page for
      vmbus_connection. Implement vmbus_disconnect() function by separating cleanup
      path from vmbus_connect().
      
      As we use hv_vmbus_con to release channels (see free_channel() in channel_mgmt.c)
      we need to make sure the work was done before we remove the queue, do that with
      drain_workqueue(). We also need to avoid handling messages  which can (potentially)
      create new channels, so set vmbus_connection.conn_state = DISCONNECTED at the very
      beginning of vmbus_exit() and check for that in vmbus_onmessage_work().
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Signed-off-by: NK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      09a19628
  23. 12 1月, 2015 1 次提交
  24. 24 9月, 2014 1 次提交
  25. 10 7月, 2014 1 次提交
  26. 29 5月, 2014 1 次提交
  27. 04 5月, 2014 2 次提交