RE: [PATCH 1/1] Staging: hv: util: Fix a bug in kvp implementation
From: KY Srinivasan
Date: Wed Oct 05 2011 - 09:30:07 EST
> -----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
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?
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/