[PATCH 1/1] Staging: hv: util: Fix a bug in kvp implementation

[PATCH 1/1] Staging: hv: util: Fix a bug in kvp implementation

[K. Y. Srinivasan]

The host gurantees that there can be only one kvp transaction active
against the guest. So, the transaction active state is needed only to
protect against spurious user level calls. The current code had a race
condition where the guest could prematurely return because the previous
transaction state was not cleared - this state was being cleared after
sending the response to the host and there was a window where the host
could notify the guest of a new transaction before the transaction active
state was properly set. 
Also deal with the case when the user mode component
does not respond in a timely fashion correctly.
I would like to thank Long Li <longli@microsoft.com>
for identifying the problem.

Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Diagnosed-by: Long Li <longli@microsoft.com>
---
 drivers/staging/hv/hv_kvp.c |   13 +++++--------
 1 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/hv/hv_kvp.c b/drivers/staging/hv/hv_kvp.c
index 9aa9ede..307aedc 100644
--- a/drivers/staging/hv/hv_kvp.c
+++ b/drivers/staging/hv/hv_kvp.c
@@ -50,6 +50,8 @@ static struct {
 
 static int kvp_send_key(int index);
 
+#define TIMEOUT_FIRED 1
+
 static void kvp_respond_to_host(char *key, char *value, int error);
 static void kvp_work_func(struct work_struct *dummy);
 static void kvp_register(void);
@@ -58,7 +60,6 @@ static DECLARE_DELAYED_WORK(kvp_work, kvp_work_func);
 
 static struct cb_id kvp_id = { CN_KVP_IDX, CN_KVP_VAL };
 static const char kvp_name[] = "kvp_kernel_module";
-static int timeout_fired;
 static u8 *recv_buffer;
 /*
  * Register the kernel component with the user-level daemon.
@@ -90,8 +91,7 @@ kvp_work_func(struct work_struct *dummy)
 	 * If the timer fires, the user-mode component has not responded;
 	 * process the pending transaction.
 	 */
-	kvp_respond_to_host("Unknown key", "Guest timed out", timeout_fired);
-	timeout_fired = 1;
+	kvp_respond_to_host("Unknown key", "Guest timed out", TIMEOUT_FIRED);
 }
 
 /*
@@ -177,6 +177,8 @@ kvp_respond_to_host(char *key, char *value, int error)
 	channel = kvp_transaction.recv_channel;
 	req_id = kvp_transaction.recv_req_id;
 
+	kvp_transaction.active = false;
+
 	if (channel->onchannel_callback == NULL)
 		/*
 		 * We have raced with util driver being unloaded;
@@ -224,7 +226,6 @@ response_done:
 	vmbus_sendpacket(channel, recv_buffer, buf_len, req_id,
 				VM_PKT_DATA_INBAND, 0);
 
-	kvp_transaction.active = false;
 }
 
 /*
@@ -250,10 +251,6 @@ void hv_kvp_onchannelcallback(void *context)
 	struct icmsg_negotiate *negop = NULL;
 
 
-	if (kvp_transaction.active)
-		return;
-
-
 	vmbus_recvpacket(channel, recv_buffer, PAGE_SIZE, &recvlen, &requestid);
 
 	if (recvlen > 0) {
-- 
1.7.4.1

Re: [PATCH 1/1] Staging: hv: util: Fix a bug in kvp implementation

[Greg KH]

On Tue, Oct 04, 2011 at 02:00:02PM -0700, K. Y. Srinivasan wrote:
> The host gurantees that there can be only one kvp transaction active
> against the guest. So, the transaction active state is needed only to
> protect against spurious user level calls. The current code had a race
> condition where the guest could prematurely return because the previous
> transaction state was not cleared - this state was being cleared after
> sending the response to the host and there was a window where the host
> could notify the guest of a new transaction before the transaction active
> state was properly set. 
> Also deal with the case when the user mode component
> does not respond in a timely fashion correctly.
> I would like to thank Long Li <longli@microsoft.com>
> for identifying the problem.

So that would be a "Reported-by:" tag, we don't have a "Diagnosed-by" do
we?

And should this go to the older (i.e. stable) kernels as well?

thanks,

greg k-h

RE: [PATCH 1/1] Staging: hv: util: Fix a bug in kvp implementation

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@suse.de]
> Sent: Wednesday, October 05, 2011 12:37 AM
> To: KY Srinivasan
> Cc: linux-kernel@vger.kernel.org; devel@linuxdriverproject.org;
> virtualization@lists.osdl.org; Long Li; Haiyang Zhang
> Subject: Re: [PATCH 1/1] Staging: hv: util: Fix a bug in kvp implementation
> 
> On Tue, Oct 04, 2011 at 02:00:02PM -0700, K. Y. Srinivasan wrote:
> > The host gurantees that there can be only one kvp transaction active
> > against the guest. So, the transaction active state is needed only to
> > protect against spurious user level calls. The current code had a race
> > condition where the guest could prematurely return because the previous
> > transaction state was not cleared - this state was being cleared after
> > sending the response to the host and there was a window where the host
> > could notify the guest of a new transaction before the transaction active
> > state was properly set.
> > Also deal with the case when the user mode component
> > does not respond in a timely fashion correctly.
> > I would like to thank Long Li <longli@microsoft.com>
> > for identifying the problem.
> 
> So that would be a "Reported-by:" tag, we don't have a "Diagnosed-by" do
> we?

Reported-by tag would do.
> 
> And should this go to the older (i.e. stable) kernels as well?
> 

While the bug can be triggered by doing something that is not the way this (KVP) 
feature is to be used, I don't think this bug can be triggered under normal usage.
The test case that exposed this bug was one where KVP values were being queried
from the host in a tight loop - hardly a typical usage scenario. So, I was not sure if this would
qualify for back porting to other stable kernels. What do you think?

Regards,

K. Y