Drivers: hv: vmbus: Add timeout to vmbus_wait_for_unload

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: 8e043bdf6869 ("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/r/1600026449-23651-1-git-send-email-mikelley@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>

diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
index 417a95e5094dd9d914eb8ab7c18971a62e15b21e..af7832e1316741bb821da9c5a127131e51e33fc0 100644 (file)
--- a/drivers/hv/channel_mgmt.c
+++ b/drivers/hv/channel_mgmt.c
@@ -750,7 +750,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
@@ -760,8 +760,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;