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

[KY Srinivasan]

> -----Original Message-----
> From: Greg KH [mailto:gregkh@xxxxxxx]
> Sent: Wednesday, October 05, 2011 12:37 AM
> To: KY Srinivasan
> Cc: linux-kernel@xxxxxxxxxxxxxxx; devel@xxxxxxxxxxxxxxxxxxxxxx;
> virtualization@xxxxxxxxxxxxxx; 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@xxxxxxxxxxxxx>
> > 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/