| Message ID | 20200917171901.3360614-2-marcelo.cerri@canonical.com |
|---|---|
| State | New |
| Headers | show |
| Series | LP:#1895527 - [linux-azure] [SRU] UBUNTU: SAUCE: Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload | expand |
LGTM Acked-by: Ian May <ian.may@canonical.com> On 2020-09-17 14:19:01 , Marcelo Henrique Cerri wrote: > From: Michael Kelley <mikelley@microsoft.com> > > BugLink: https://bugs.launchpad.net/bugs/1895527 > > vmbus_wait_for_unload() looks for a CHANNELMSG_UNLOAD_RESPONSE message > coming from Hyper-V. But if the message isn't found for some reason, > the panic path gets hung forever. Add a timeout of 10 seconds to prevent > this. > > Fixes: 415719160de3 ("Drivers: hv: vmbus: avoid scheduling in interrupt context in vmbus_initiate_unload()") > Signed-off-by: Michael Kelley <mikelley@microsoft.com> > Reviewed-by: Dexuan Cui <decui@microsoft.com> > Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com> > > Link: https://lore.kernel.org/linux-hyperv/1600026449-23651-1-git-send-email-mikelley@microsoft.com/ > Signed-off-by: Marcelo Henrique Cerri <marcelo.cerri@canonical.com> > --- > drivers/hv/channel_mgmt.c | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c > index 501c43c5851d..452307c79e4b 100644 > --- a/drivers/hv/channel_mgmt.c > +++ b/drivers/hv/channel_mgmt.c > @@ -769,7 +769,7 @@ static void vmbus_wait_for_unload(void) > void *page_addr; > struct hv_message *msg; > struct vmbus_channel_message_header *hdr; > - u32 message_type; > + u32 message_type, i; > > /* > * CHANNELMSG_UNLOAD_RESPONSE is always delivered to the CPU which was > @@ -779,8 +779,11 @@ static void vmbus_wait_for_unload(void) > * functional and vmbus_unload_response() will complete > * vmbus_connection.unload_event. If not, the last thing we can do is > * read message pages for all CPUs directly. > + * > + * Wait no more than 10 seconds so that the panic path can't get > + * hung forever in case the response message isn't seen. > */ > - while (1) { > + for (i = 0; i < 1000; i++) { > if (completion_done(&vmbus_connection.unload_event)) > break; > > -- > 2.25.1 > > > -- > kernel-team mailing list > kernel-team@lists.ubuntu.com > https://lists.ubuntu.com/mailman/listinfo/kernel-team
diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c index 501c43c5851d..452307c79e4b 100644 --- a/drivers/hv/channel_mgmt.c +++ b/drivers/hv/channel_mgmt.c @@ -769,7 +769,7 @@ static void vmbus_wait_for_unload(void) void *page_addr; struct hv_message *msg; struct vmbus_channel_message_header *hdr; - u32 message_type; + u32 message_type, i; /* * CHANNELMSG_UNLOAD_RESPONSE is always delivered to the CPU which was @@ -779,8 +779,11 @@ static void vmbus_wait_for_unload(void) * functional and vmbus_unload_response() will complete * vmbus_connection.unload_event. If not, the last thing we can do is * read message pages for all CPUs directly. + * + * Wait no more than 10 seconds so that the panic path can't get + * hung forever in case the response message isn't seen. */ - while (1) { + for (i = 0; i < 1000; i++) { if (completion_done(&vmbus_connection.unload_event)) break;