* [PATCH 1/1] Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload
@ 2020-09-13 19:47 Michael Kelley
2020-09-13 19:56 ` Dexuan Cui
2020-09-14 10:09 ` ** POTENTIAL FRAUD ALERT - RED HAT ** " Vitaly Kuznetsov
0 siblings, 2 replies; 4+ messages in thread
From: Michael Kelley @ 2020-09-13 19:47 UTC (permalink / raw)
To: linux-kernel, vkuznets, kys, sthemmin, wei.liu, linux-hyperv; +Cc: mikelley
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>
---
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 591106c..1d44bb6 100644
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -731,7 +731,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
@@ -741,8 +741,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;
--
1.8.3.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* RE: [PATCH 1/1] Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload
2020-09-13 19:47 [PATCH 1/1] Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload Michael Kelley
@ 2020-09-13 19:56 ` Dexuan Cui
2020-09-14 9:02 ` Wei Liu
2020-09-14 10:09 ` ** POTENTIAL FRAUD ALERT - RED HAT ** " Vitaly Kuznetsov
1 sibling, 1 reply; 4+ messages in thread
From: Dexuan Cui @ 2020-09-13 19:56 UTC (permalink / raw)
To: Michael Kelley, linux-kernel, vkuznets, KY Srinivasan,
Stephen Hemminger, wei.liu, linux-hyperv
Cc: Michael Kelley
> From: linux-hyperv-owner@vger.kernel.org
> <linux-hyperv-owner@vger.kernel.org> On Behalf Of Michael Kelley
> Sent: Sunday, September 13, 2020 12:47 PM
>
> 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>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH 1/1] Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload
2020-09-13 19:56 ` Dexuan Cui
@ 2020-09-14 9:02 ` Wei Liu
0 siblings, 0 replies; 4+ messages in thread
From: Wei Liu @ 2020-09-14 9:02 UTC (permalink / raw)
To: Dexuan Cui
Cc: Michael Kelley, linux-kernel, vkuznets, KY Srinivasan,
Stephen Hemminger, wei.liu, linux-hyperv
On Sun, Sep 13, 2020 at 07:56:30PM +0000, Dexuan Cui wrote:
> > From: linux-hyperv-owner@vger.kernel.org
> > <linux-hyperv-owner@vger.kernel.org> On Behalf Of Michael Kelley
> > Sent: Sunday, September 13, 2020 12:47 PM
> >
> > 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>
LGTM.
Applied to hyperv-fixes. Thanks.
Wei.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: ** POTENTIAL FRAUD ALERT - RED HAT ** [PATCH 1/1] Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload
2020-09-13 19:47 [PATCH 1/1] Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload Michael Kelley
2020-09-13 19:56 ` Dexuan Cui
@ 2020-09-14 10:09 ` Vitaly Kuznetsov
1 sibling, 0 replies; 4+ messages in thread
From: Vitaly Kuznetsov @ 2020-09-14 10:09 UTC (permalink / raw)
To: Michael Kelley; +Cc: linux-kernel, kys, sthemmin, wei.liu, linux-hyperv
Michael Kelley <mikelley@microsoft.com> writes:
> 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.
If I remember correctly, the problem I was observing back then was that
if CHANNELMSG_UNLOAD_RESPONSE is not delivered, Hyper-V won't respond to
the consequent CHANNELMSG_INITIATE_CONTACT/CHANNELMSG_REQUESTOFFERS
(don't remember exactly) so we either hang here or crash in the kdump
kernel because we can't find any devices. Maybe the problem was only
with some ancient Hyper-V versions or it was fixed.
>
> Fixes: 415719160de3 ("Drivers: hv: vmbus: avoid scheduling in interrupt context in vmbus_initiate_unload()")
> Signed-off-by: Michael Kelley <mikelley@microsoft.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 591106c..1d44bb6 100644
> --- a/drivers/hv/channel_mgmt.c
> +++ b/drivers/hv/channel_mgmt.c
> @@ -731,7 +731,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
> @@ -741,8 +741,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;
LGTM,
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
--
Vitaly
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-09-14 10:09 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-13 19:47 [PATCH 1/1] Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload Michael Kelley
2020-09-13 19:56 ` Dexuan Cui
2020-09-14 9:02 ` Wei Liu
2020-09-14 10:09 ` ** POTENTIAL FRAUD ALERT - RED HAT ** " Vitaly Kuznetsov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).