Re: [Xen-devel] Xenbus behaviour

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

On Thu, Dec 14, 2006 at 09:56:45AM -0500, Glauber de Oliveira Costa wrote:

> On Thu, 2006-12-14 at 08:24 +0000, Keir Fraser wrote:
> > On 13/12/06 8:11 pm, "Glauber de Oliveira Costa" <gcosta@xxxxxxxxxx> wrote:
> > 
> > > I've noticed today that some xenbus state changes are reported twice, as
> > > in the follow example from dmesg:
> > > 
> > > state is 4 (Connected), /local/domain/8/device/vif/4/state,
> > > /local/domain/8/device/vif/4/stateDele
> > > state is 4 (Connected), /local/domain/8/device/vif/4/state,
> > > /local/domain/8/device/vif/4/stateDele
> > > 
> > > I'm not sure whether this is legal or a bug.
> > 
> > It's certainly legal, but a bit surprising and annoying. Only the 'state'
> > node is watched, so presumably it is getting written to twice?
> 
> I'm not yet sure about the root of this problem. But from what I've
> gathered so far, it seems (I'll try confirming this today) that the two
> fires are actually happening. But one of them is for InitWait, and the
> other one is for Closing. But when the first one is read, Closing state
> has already been written in the store, overwriting the old value. (It is
> not the situation that is shown in the log, tough. I'm analyzing it more
> on the guest side now). Result is that guest reads Closing twice, when
> it should be reading InitWait and Closing. Do you think this is a
> reasonable hypothesis ? 
> 
> Moreover, if multiple triggers are indeed valid, we should maybe take
> extra care about double fires in drivers. For example, this situation I'
> m describing crashes xennet on domU, because when receiving the second
> Closing, it tries to unregister_netdev() again, in an invalid state. 

That sounds like a reasonable hypothesis, yes, and it definitely needs
fixing.  There's always going to be a race between the watch firing and the
driver coming back to read things that may change underneath.  The watch
should always mean "something might have changed, go check", and nothing more
precise than that.

Ewan.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel