Re: [Xen-devel] [PATCH 4/4] review For Oracle bug 14470382

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2013-01-18 at 06:45 +0000, Dan Carpenter wrote:
> On Fri, Jan 18, 2013 at 09:57:48AM +0800, jianhai luan wrote:
> > +/**
> > + * By Connected->Connected transition, netfront will watch the change and
> > + * send gratuitous ARP.
> > + */
> > +static void notify_front_arping(struct xenbus_device *dev)
> > +{
> > +   struct xenbus_transaction xbt;
> > +   int err;
> > +
> > +   if (xenbus_read_driver_state(dev->nodename) != XenbusStateConnected)
> > +           return;
> > +
> > +again:
> > +   err = xenbus_transaction_start(&xbt);
> > +   if (err) {
> > +           printk(KERN_ALERT "Error starting transaction");
> > +           return;
> > +   }
> > +
> > +   err = xenbus_printf(xbt, dev->nodename, "state", "%d", dev->state);
> > +   if(err) {
> > +           printk(KERN_ALERT "Error writing the state");
> > +           xenbus_transaction_end(xbt, 1);
> > +           return;
> > +   }
> > +   
> > +   err = xenbus_transaction_end(xbt, 0);
> > +   if (err == -EAGAIN)
> > +           goto again;
> 
> Why would we get a -EAGAIN here?  My reading says that it would have
> to come as the msg->body from the XenServer.  I would be tempted to
> just ignore those errors.

EAGAIN is what the xenstore daemon returns when a transaction fails,
e.g. due to a conflicting change. 

However a single xenbus_printf as used here doesn't need a transaction
since it is only a single atomic operation.

On the other hand I'm not convinced that the initial read of the current
state didn't ought to be inside the transaction too, although I've not
thought about it terribly hard...

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel