Drivers: hv: vmbus: don't loose HVMSG_TIMER_EXPIRED messages

BugLink: http://bugs.launchpad.net/bugs/1541585

We must handle HVMSG_TIMER_EXPIRED messages in the interrupt context
and we offload all the rest to vmbus_on_msg_dpc() tasklet. This functions
loops to see if there are new messages pending. In case we'll ever see
HVMSG_TIMER_EXPIRED message there we're going to lose it as we can't
handle it from there. Avoid looping in vmbus_on_msg_dpc(), we're OK
with handling one message per interrupt.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Radim Kr.má<rkrcmar@redhat.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 7be3e169)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>

drivers/hv/vmbus_drv.c

@@ -739,10 +739,9 @@ void vmbus_on_msg_dpc(unsigned long data)
 	struct vmbus_channel_message_table_entry *entry;
 	struct onmessage_work_context *ctx;
 
-	while (1) {
 	if (msg->header.message_type == HVMSG_NONE)
 		/* no msg */
-			break;
+		return;
 
 	hdr = (struct vmbus_channel_message_header *)msg->u.payload;
 
@@ -755,7 +754,7 @@ void vmbus_on_msg_dpc(unsigned long data)
 	if (entry->handler_type	== VMHT_BLOCKING) {
 		ctx = kmalloc(sizeof(*ctx), GFP_ATOMIC);
 		if (ctx == NULL)
-				continue;
+			return;
 
 		INIT_WORK(&ctx->work, vmbus_onmessage_work);
 		memcpy(&ctx->msg, msg, sizeof(*msg));
@@ -784,7 +783,6 @@ void vmbus_on_msg_dpc(unsigned long data)
 		 */
 		wrmsrl(HV_X64_MSR_EOM, 0);
 	}
-	}
 }
 
 static void vmbus_isr(void)