This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'. If the problem still exists,
change the tag 'verification-needed-xenial' to 'verification-failed-
xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

** Tags added: verification-needed-yakkety

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1681893

Title:
  [Hyper-V] hv: vmbus: Raise retry/wait limits in vmbus_post_msg()

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  In Progress
Status in linux source package in Yakkety:
  In Progress
Status in linux source package in Zesty:
  Fix Released

Bug description:
  We've been hitting provisioning errors in Azure and narrowed down the
  cause to vmbus_post_msg timeouts. This upstream commit should
  alleviate this.

  https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-
  next.git/commit/?id=c0bb03924f1a80e7f65900e36c8e6b3dc167c5f8

  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 <vkuzn...@redhat.com>
  Signed-off-by: K. Y. Srinivasan <k...@microsoft.com>
  Cc: <sta...@vger.kernel.org>
  Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1681893/+subscriptions

-- 
Mailing list: https://launchpad.net/~kernel-packages
Post to     : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to