mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: devel@linuxdriverproject.org
Cc: linux-kernel@vger.kernel.org,
	"K. Y. Srinivasan" <kys@microsoft.com>,
	Haiyang Zhang <haiyangz@microsoft.com>
Subject: [PATCH] Drivers: hv: fix infinite wait when channel open timeouts
Date: Fri,  3 Jun 2016 12:14:51 +0200	[thread overview]
Message-ID: <1464948891-5532-1-git-send-email-vkuznets@redhat.com> (raw)

vmbus_teardown_gpadl() can result in infinite wait when it is called
on 5 second timeout in vmbus_open(). The issue is caused by the fact
that gpadl teardown operation won't ever succeed for an opened channel
and the timeout isn't always enough. Increase the timeout to 15 seconds
and add sending CHANNELMSG_CLOSECHANNEL message on timeout to make sure
the channel is closed.

The other possible solution for the issue would be to remove the timeout
in vmbus_open() making our wait infinite.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
---
 drivers/hv/channel.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c
index 6a8660d..becb9e8 100644
--- a/drivers/hv/channel.c
+++ b/drivers/hv/channel.c
@@ -69,6 +69,7 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 send_ringbuffer_size,
 		     void (*onchannelcallback)(void *context), void *context)
 {
 	struct vmbus_channel_open_channel *open_msg;
+	struct vmbus_channel_close_channel *close_msg;
 	struct vmbus_channel_msginfo *open_info = NULL;
 	void *in, *out;
 	unsigned long flags;
@@ -183,8 +184,19 @@ int vmbus_open(struct vmbus_channel *newchannel, u32 send_ringbuffer_size,
 		goto error1;
 	}
 
-	t = wait_for_completion_timeout(&open_info->waitevent, 5*HZ);
+	t = wait_for_completion_timeout(&open_info->waitevent, 15*HZ);
 	if (t == 0) {
+		/*
+		 * We won't be able to tear down the gpadl handle if the
+		 * channel finally gets openned, send channel close message
+		 * to be on the safe side.
+		 */
+		close_msg = &newchannel->close_msg.msg;
+		close_msg->header.msgtype = CHANNELMSG_CLOSECHANNEL;
+		close_msg->child_relid = newchannel->offermsg.child_relid;
+		vmbus_post_msg(close_msg,
+			       sizeof(struct vmbus_channel_close_channel));
+
 		err = -ETIMEDOUT;
 		goto error1;
 	}
-- 
2.5.5

             reply	other threads:[~2016-06-03 10:14 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-03 10:14 Vitaly Kuznetsov [this message]
2016-06-03 20:05 ` KY Srinivasan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1464948891-5532-1-git-send-email-vkuznets@redhat.com \
    --to=vkuznets@redhat.com \
    --cc=devel@linuxdriverproject.org \
    --cc=haiyangz@microsoft.com \
    --cc=kys@microsoft.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®