[SRU][Cosmic][PATCH 0/2] Fixes for LP:1807757

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[SRU][Cosmic][PATCH 0/2] Fixes for LP:1807757

Joseph Salisbury-3
BugLink: https://bugs.launchpad.net/bugs/1807757

== SRU Justification ==
Microsoft has identified a multiple-NIC-deadlock issue on Hyper-V VMs.
This bug is fixed by the commits eceb05965489 and 37c2578c0c40.

These commits fix a regression introduced by mainline commit 8195b1396ec8,
and both have been cc'd upstream stable but has not landed in Cosmic as of
yet.

These commits are also needed in Bionic and linux-azure, but they also
have some dependent commits.  Due to this, their SRU requests will
be sent separate.

== Fixes ==
eceb05965489 ("Drivers: hv: vmbus: check the creation_status in vmbus_establish_gpadl()
37c2578c0c40 ("Drivers: hv: vmbus: Offload the handling of channels to two workqueues")

== Regression Potential ==
Low, limited to hyperv.

== Test Case ==
Microsoft ran tests with these commits are confirm they resolve the bug
and do not introduce any regressions.


Dexuan Cui (2):
  Drivers: hv: vmbus: check the creation_status in
    vmbus_establish_gpadl()
  Drivers: hv: vmbus: Offload the handling of channels to two workqueues

 drivers/hv/channel.c      |   8 ++
 drivers/hv/channel_mgmt.c | 190 +++++++++++++++++++++++++++++++---------------
 drivers/hv/connection.c   |  24 +++++-
 drivers/hv/hyperv_vmbus.h |   7 ++
 include/linux/hyperv.h    |   7 ++
 5 files changed, 170 insertions(+), 66 deletions(-)

--
2.7.4


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[SRU][Cosmic][PATCH 1/2] Drivers: hv: vmbus: check the creation_status in vmbus_establish_gpadl()

Joseph Salisbury-3
From: Dexuan Cui <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1807757

This is a longstanding issue: if the vmbus upper-layer drivers try to
consume too many GPADLs, the host may return with an error
0xC0000044 (STATUS_QUOTA_EXCEEDED), but currently we forget to check
the creation_status, and hence we can pass an invalid GPADL handle
into the OPEN_CHANNEL message, and get an error code 0xc0000225 in
open_info->response.open_result.status, and finally we hang in
vmbus_open() -> "goto error_free_info" -> vmbus_teardown_gpadl().

With this patch, we can exit gracefully on STATUS_QUOTA_EXCEEDED.

Cc: Stephen Hemminger <[hidden email]>
Cc: K. Y. Srinivasan <[hidden email]>
Cc: Haiyang Zhang <[hidden email]>
Cc: [hidden email]
Signed-off-by: Dexuan Cui <[hidden email]>
Signed-off-by: K. Y. Srinivasan <[hidden email]>
Signed-off-by: Greg Kroah-Hartman <[hidden email]>
(cherry picked from commit eceb05965489784f24bbf4d61ba60e475a983016)
Signed-off-by: Joseph Salisbury <[hidden email]>
---
 drivers/hv/channel.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index c394922..5898669 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -469,6 +469,14 @@ int vmbus_establish_gpadl(struct vmbus_channel *channel, void *kbuffer,
  }
  wait_for_completion(&msginfo->waitevent);
 
+ if (msginfo->response.gpadl_created.creation_status != 0) {
+ pr_err("Failed to establish GPADL: err = 0x%x\n",
+       msginfo->response.gpadl_created.creation_status);
+
+ ret = -EDQUOT;
+ goto cleanup;
+ }
+
  if (channel->rescind) {
  ret = -ENODEV;
  goto cleanup;
--
2.7.4


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

[SRU][Cosmic][PATCH 2/2] Drivers: hv: vmbus: Offload the handling of channels to two workqueues

Joseph Salisbury-3
In reply to this post by Joseph Salisbury-3
From: Dexuan Cui <[hidden email]>

BugLink: https://bugs.launchpad.net/bugs/1807757

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 8195b1396ec8.

Fixes: 8195b1396ec8 ("hv_netvsc: fix deadlock on hotplug")
Cc: [hidden email]
Cc: Stephen Hemminger <[hidden email]>
Cc: K. Y. Srinivasan <[hidden email]>
Cc: Haiyang Zhang <[hidden email]>
Signed-off-by: Dexuan Cui <[hidden email]>
Signed-off-by: K. Y. Srinivasan <[hidden email]>
Signed-off-by: Greg Kroah-Hartman <[hidden email]>
(backported from commit 37c2578c0c40e286bc0d30bdc05290b2058cf66e)
Signed-off-by: Joseph Salisbury <[hidden email]>
---
 drivers/hv/channel_mgmt.c | 190 +++++++++++++++++++++++++++++++---------------
 drivers/hv/connection.c   |  24 +++++-
 drivers/hv/hyperv_vmbus.h |   7 ++
 include/linux/hyperv.h    |   7 ++
 4 files changed, 162 insertions(+), 66 deletions(-)

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 0f0e091..70720ba 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -447,61 +447,16 @@ void vmbus_free_channels(void)
  }
 }
 
-/*
- * vmbus_process_offer - Process the offer by creating a channel/device
- * associated with this offer
- */
-static void vmbus_process_offer(struct vmbus_channel *newchannel)
+/* Note: the function can run concurrently for primary/sub channels. */
+static void vmbus_add_channel_work(struct work_struct *work)
 {
- struct vmbus_channel *channel;
- bool fnew = true;
+ struct vmbus_channel *newchannel =
+ container_of(work, struct vmbus_channel, add_channel_work);
+ struct vmbus_channel *primary_channel = newchannel->primary_channel;
  unsigned long flags;
  u16 dev_type;
  int ret;
 
- /* Make sure this is a new offer */
- mutex_lock(&vmbus_connection.channel_mutex);
-
- /*
- * Now that we have acquired the channel_mutex,
- * we can release the potentially racing rescind thread.
- */
- atomic_dec(&vmbus_connection.offer_in_progress);
-
- list_for_each_entry(channel, &vmbus_connection.chn_list, listentry) {
- if (!uuid_le_cmp(channel->offermsg.offer.if_type,
- newchannel->offermsg.offer.if_type) &&
- !uuid_le_cmp(channel->offermsg.offer.if_instance,
- newchannel->offermsg.offer.if_instance)) {
- fnew = false;
- break;
- }
- }
-
- if (fnew)
- list_add_tail(&newchannel->listentry,
-      &vmbus_connection.chn_list);
-
- mutex_unlock(&vmbus_connection.channel_mutex);
-
- if (!fnew) {
- /*
- * Check to see if this is a sub-channel.
- */
- if (newchannel->offermsg.offer.sub_channel_index != 0) {
- /*
- * Process the sub-channel.
- */
- newchannel->primary_channel = channel;
- spin_lock_irqsave(&channel->lock, flags);
- list_add_tail(&newchannel->sc_list, &channel->sc_list);
- channel->num_sc++;
- spin_unlock_irqrestore(&channel->lock, flags);
- } else {
- goto err_free_chan;
- }
- }
-
  dev_type = hv_get_dev_type(newchannel);
 
  init_vp_index(newchannel, dev_type);
@@ -519,27 +474,26 @@ static void vmbus_process_offer(struct vmbus_channel *newchannel)
  /*
  * This state is used to indicate a successful open
  * so that when we do close the channel normally, we
- * can cleanup properly
+ * can cleanup properly.
  */
  newchannel->state = CHANNEL_OPEN_STATE;
 
- if (!fnew) {
- struct hv_device *dev
- = newchannel->primary_channel->device_obj;
+ if (primary_channel != NULL) {
+ /* newchannel is a sub-channel. */
+ struct hv_device *dev = primary_channel->device_obj;
 
  if (vmbus_add_channel_kobj(dev, newchannel))
- goto err_free_chan;
+ goto err_deq_chan;
+
+ if (primary_channel->sc_creation_callback != NULL)
+ primary_channel->sc_creation_callback(newchannel);
 
- if (channel->sc_creation_callback != NULL)
- channel->sc_creation_callback(newchannel);
  newchannel->probe_done = true;
  return;
  }
 
  /*
- * Start the process of binding this offer to the driver
- * We need to set the DeviceObject field before calling
- * vmbus_child_dev_add()
+ * Start the process of binding the primary channel to the driver
  */
  newchannel->device_obj = vmbus_device_create(
  &newchannel->offermsg.offer.if_type,
@@ -568,13 +522,28 @@ static void vmbus_process_offer(struct vmbus_channel *newchannel)
 
 err_deq_chan:
  mutex_lock(&vmbus_connection.channel_mutex);
- list_del(&newchannel->listentry);
+
+ /*
+ * We need to set the flag, otherwise
+ * vmbus_onoffer_rescind() can be blocked.
+ */
+ newchannel->probe_done = true;
+
+ if (primary_channel == NULL) {
+ list_del(&newchannel->listentry);
+ } else {
+ spin_lock_irqsave(&primary_channel->lock, flags);
+ list_del(&newchannel->sc_list);
+ spin_unlock_irqrestore(&primary_channel->lock, flags);
+ }
+
  mutex_unlock(&vmbus_connection.channel_mutex);
 
  if (newchannel->target_cpu != get_cpu()) {
  put_cpu();
  smp_call_function_single(newchannel->target_cpu,
- percpu_channel_deq, newchannel, true);
+ percpu_channel_deq,
+ newchannel, true);
  } else {
  percpu_channel_deq(newchannel);
  put_cpu();
@@ -582,14 +551,104 @@ static void vmbus_process_offer(struct vmbus_channel *newchannel)
 
  vmbus_release_relid(newchannel->offermsg.child_relid);
 
-err_free_chan:
  free_channel(newchannel);
 }
 
 /*
+ * vmbus_process_offer - Process the offer by creating a channel/device
+ * associated with this offer
+ */
+static void vmbus_process_offer(struct vmbus_channel *newchannel)
+{
+ struct vmbus_channel *channel;
+ struct workqueue_struct *wq;
+ unsigned long flags;
+ bool fnew = true;
+
+ mutex_lock(&vmbus_connection.channel_mutex);
+
+ /*
+ * Now that we have acquired the channel_mutex,
+ * we can release the potentially racing rescind thread.
+ */
+ atomic_dec(&vmbus_connection.offer_in_progress);
+
+ list_for_each_entry(channel, &vmbus_connection.chn_list, listentry) {
+ if (!uuid_le_cmp(channel->offermsg.offer.if_type,
+ newchannel->offermsg.offer.if_type) &&
+    !uuid_le_cmp(channel->offermsg.offer.if_instance,
+ newchannel->offermsg.offer.if_instance)) {
+ fnew = false;
+ break;
+ }
+ }
+
+ if (fnew)
+ list_add_tail(&newchannel->listentry,
+      &vmbus_connection.chn_list);
+ else {
+ /*
+ * Check to see if this is a valid sub-channel.
+ */
+ if (newchannel->offermsg.offer.sub_channel_index == 0) {
+ mutex_unlock(&vmbus_connection.channel_mutex);
+ /*
+ * Don't call free_channel(), because newchannel->kobj
+ * is not initialized yet.
+ */
+ kfree(newchannel);
+ WARN_ON_ONCE(1);
+ return;
+ }
+ /*
+ * Process the sub-channel.
+ */
+ newchannel->primary_channel = channel;
+ spin_lock_irqsave(&channel->lock, flags);
+ list_add_tail(&newchannel->sc_list, &channel->sc_list);
+ spin_unlock_irqrestore(&channel->lock, flags);
+ }
+
+ mutex_unlock(&vmbus_connection.channel_mutex);
+
+ /*
+ * 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.
+ */
+ INIT_WORK(&newchannel->add_channel_work, vmbus_add_channel_work);
+ wq = fnew ? vmbus_connection.handle_primary_chan_wq :
+    vmbus_connection.handle_sub_chan_wq;
+ queue_work(wq, &newchannel->add_channel_work);
+}
+
+/*
  * We use this state to statically distribute the channel interrupt load.
  */
 static int next_numa_node_id;
+/*
+ * init_vp_index() accesses global variables like next_numa_node_id, and
+ * it can run concurrently for primary channels and sub-channels: see
+ * vmbus_process_offer(), so we need the lock to protect the global
+ * variables.
+ */
+static DEFINE_SPINLOCK(bind_channel_to_cpu_lock);
 
 /*
  * Starting with Win8, we can statically distribute the incoming
@@ -623,6 +682,8 @@ static void init_vp_index(struct vmbus_channel *channel, u16 dev_type)
  return;
  }
 
+ spin_lock(&bind_channel_to_cpu_lock);
+
  /*
  * Based on the channel affinity policy, we will assign the NUMA
  * nodes.
@@ -704,6 +765,9 @@ static void init_vp_index(struct vmbus_channel *channel, u16 dev_type)
 
  channel->target_cpu = cur_cpu;
  channel->target_vp = hv_cpu_number_to_vp_number(cur_cpu);
+
+ spin_unlock(&bind_channel_to_cpu_lock);
+
 }
 
 static void vmbus_wait_for_unload(void)
diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
index f4d08c8..4fe117b7 100644
--- a/drivers/hv/connection.c
+++ b/drivers/hv/connection.c
@@ -190,6 +190,20 @@ int vmbus_connect(void)
  goto cleanup;
  }
 
+ vmbus_connection.handle_primary_chan_wq =
+ create_workqueue("hv_pri_chan");
+ if (!vmbus_connection.handle_primary_chan_wq) {
+ ret = -ENOMEM;
+ goto cleanup;
+ }
+
+ vmbus_connection.handle_sub_chan_wq =
+ create_workqueue("hv_sub_chan");
+ if (!vmbus_connection.handle_sub_chan_wq) {
+ ret = -ENOMEM;
+ goto cleanup;
+ }
+
  INIT_LIST_HEAD(&vmbus_connection.chn_msg_list);
  spin_lock_init(&vmbus_connection.channelmsg_lock);
 
@@ -280,10 +294,14 @@ void vmbus_disconnect(void)
  */
  vmbus_initiate_unload(false);
 
- if (vmbus_connection.work_queue) {
- drain_workqueue(vmbus_connection.work_queue);
+ if (vmbus_connection.handle_sub_chan_wq)
+ destroy_workqueue(vmbus_connection.handle_sub_chan_wq);
+
+ if (vmbus_connection.handle_primary_chan_wq)
+ destroy_workqueue(vmbus_connection.handle_primary_chan_wq);
+
+ if (vmbus_connection.work_queue)
  destroy_workqueue(vmbus_connection.work_queue);
- }
 
  if (vmbus_connection.int_page) {
  free_pages((unsigned long)vmbus_connection.int_page, 0);
diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 72eaba3..87d3d7d 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -335,7 +335,14 @@ struct vmbus_connection {
  struct list_head chn_list;
  struct mutex channel_mutex;
 
+ /*
+ * An offer message is handled first on the work_queue, and then
+ * is further handled on handle_primary_chan_wq or
+ * handle_sub_chan_wq.
+ */
  struct workqueue_struct *work_queue;
+ struct workqueue_struct *handle_primary_chan_wq;
+ struct workqueue_struct *handle_sub_chan_wq;
 };
 
 
diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h
index 5389012..56451ae 100644
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -889,6 +889,13 @@ struct vmbus_channel {
 
  bool probe_done;
 
+ /*
+ * We must offload the handling of the primary/sub channels
+ * from the single-threaded vmbus_connection.work_queue to
+ * two different workqueue, otherwise we can block
+ * vmbus_connection.work_queue and hang: see vmbus_process_offer().
+ */
+ struct work_struct add_channel_work;
 };
 
 static inline bool is_hvsock_channel(const struct vmbus_channel *c)
--
2.7.4


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

ACK: [SRU][Cosmic][PATCH 0/2] Fixes for LP:1807757

Khaled Elmously
In reply to this post by Joseph Salisbury-3
On 2018-12-19 10:55:45 , Joseph Salisbury wrote:

> BugLink: https://bugs.launchpad.net/bugs/1807757
>
> == SRU Justification ==
> Microsoft has identified a multiple-NIC-deadlock issue on Hyper-V VMs.
> This bug is fixed by the commits eceb05965489 and 37c2578c0c40.
>
> These commits fix a regression introduced by mainline commit 8195b1396ec8,
> and both have been cc'd upstream stable but has not landed in Cosmic as of
> yet.
>
> These commits are also needed in Bionic and linux-azure, but they also
> have some dependent commits.  Due to this, their SRU requests will
> be sent separate.
>
> == Fixes ==
> eceb05965489 ("Drivers: hv: vmbus: check the creation_status in vmbus_establish_gpadl()
> 37c2578c0c40 ("Drivers: hv: vmbus: Offload the handling of channels to two workqueues")
>
> == Regression Potential ==
> Low, limited to hyperv.
>
> == Test Case ==
> Microsoft ran tests with these commits are confirm they resolve the bug
> and do not introduce any regressions.
>
>
> Dexuan Cui (2):
>   Drivers: hv: vmbus: check the creation_status in
>     vmbus_establish_gpadl()
>   Drivers: hv: vmbus: Offload the handling of channels to two workqueues
>
>  drivers/hv/channel.c      |   8 ++
>  drivers/hv/channel_mgmt.c | 190 +++++++++++++++++++++++++++++++---------------
>  drivers/hv/connection.c   |  24 +++++-
>  drivers/hv/hyperv_vmbus.h |   7 ++
>  include/linux/hyperv.h    |   7 ++
>  5 files changed, 170 insertions(+), 66 deletions(-)
>

Acked-by: Khalid Elmously <[hidden email]>


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

ACK: [SRU][Cosmic][PATCH 0/2] Fixes for LP:1807757

Kleber Souza
In reply to this post by Joseph Salisbury-3
On 12/19/18 4:55 PM, Joseph Salisbury wrote:

> BugLink: https://bugs.launchpad.net/bugs/1807757
>
> == SRU Justification ==
> Microsoft has identified a multiple-NIC-deadlock issue on Hyper-V VMs.
> This bug is fixed by the commits eceb05965489 and 37c2578c0c40.
>
> These commits fix a regression introduced by mainline commit 8195b1396ec8,
> and both have been cc'd upstream stable but has not landed in Cosmic as of
> yet.
>
> These commits are also needed in Bionic and linux-azure, but they also
> have some dependent commits.  Due to this, their SRU requests will
> be sent separate.
>
> == Fixes ==
> eceb05965489 ("Drivers: hv: vmbus: check the creation_status in vmbus_establish_gpadl()
> 37c2578c0c40 ("Drivers: hv: vmbus: Offload the handling of channels to two workqueues")
>
> == Regression Potential ==
> Low, limited to hyperv.
>
> == Test Case ==
> Microsoft ran tests with these commits are confirm they resolve the bug
> and do not introduce any regressions.
>
>
> Dexuan Cui (2):
>   Drivers: hv: vmbus: check the creation_status in
>     vmbus_establish_gpadl()
>   Drivers: hv: vmbus: Offload the handling of channels to two workqueues
>
>  drivers/hv/channel.c      |   8 ++
>  drivers/hv/channel_mgmt.c | 190 +++++++++++++++++++++++++++++++---------------
>  drivers/hv/connection.c   |  24 +++++-
>  drivers/hv/hyperv_vmbus.h |   7 ++
>  include/linux/hyperv.h    |   7 ++
>  5 files changed, 170 insertions(+), 66 deletions(-)
>
Limited to hyperv, good test results:

Acked-by: Kleber Sacilotto de Souza <[hidden email]>


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team
Reply | Threaded
Open this post in threaded view
|

APPLIED/cmnt: [SRU][Cosmic][PATCH 0/2] Fixes for LP:1807757

Kleber Souza
In reply to this post by Joseph Salisbury-3
On 12/19/18 4:55 PM, Joseph Salisbury wrote:

> BugLink: https://bugs.launchpad.net/bugs/1807757
>
> == SRU Justification ==
> Microsoft has identified a multiple-NIC-deadlock issue on Hyper-V VMs.
> This bug is fixed by the commits eceb05965489 and 37c2578c0c40.
>
> These commits fix a regression introduced by mainline commit 8195b1396ec8,
> and both have been cc'd upstream stable but has not landed in Cosmic as of
> yet.
>
> These commits are also needed in Bionic and linux-azure, but they also
> have some dependent commits.  Due to this, their SRU requests will
> be sent separate.
>
> == Fixes ==
> eceb05965489 ("Drivers: hv: vmbus: check the creation_status in vmbus_establish_gpadl()
> 37c2578c0c40 ("Drivers: hv: vmbus: Offload the handling of channels to two workqueues")
>
> == Regression Potential ==
> Low, limited to hyperv.
>
> == Test Case ==
> Microsoft ran tests with these commits are confirm they resolve the bug
> and do not introduce any regressions.
>
>
> Dexuan Cui (2):
>   Drivers: hv: vmbus: check the creation_status in
>     vmbus_establish_gpadl()
>   Drivers: hv: vmbus: Offload the handling of channels to two workqueues
>
>  drivers/hv/channel.c      |   8 ++
>  drivers/hv/channel_mgmt.c | 190 +++++++++++++++++++++++++++++++---------------
>  drivers/hv/connection.c   |  24 +++++-
>  drivers/hv/hyperv_vmbus.h |   7 ++
>  include/linux/hyperv.h    |   7 ++
>  5 files changed, 170 insertions(+), 66 deletions(-)
>
Applied to cosmic/master-next branch, with some minor changes to patch
2/2. A context adjustment was needed for the changes on
drivers/hv/channel_mgmt.c:init_vp_index(), since in the meantime the
backport for commit 25355252607c ("Drivers: hv: vmbus: Use cpumask_var_t
for on-stack cpu mask") has been applied.


Thanks,
Kleber


--
kernel-team mailing list
[hidden email]
https://lists.ubuntu.com/mailman/listinfo/kernel-team