orabug: 14470382 When Dom0''s network environment change, for example the issue, DomU should send send gratuitous ARP initially to notify how to reach it. To fix the bug, we should modify backend and frontend at the same time. For fixing frontend, i filer the new bug 16182568. The review only to backend. For fixing the backend, I have 4 patch for review. Thanks, Jason
On 2013-1-18 9:46, jianhai luan wrote:> orabug: 14470382 > > When Dom0''s network environment change, for example the issue, DomU > should send send gratuitous ARP initially to notify how to reach it. > > To fix the bug, we should modify backend and frontend at the same > time. For fixing frontend, i filer the new bug 16182568. The review > only to backend. > > For fixing the backend, I have 4 patch for review.[PATCH] net/core: add NETDEV_BONDING_FAILOVER event> > Thanks, > Jason_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 2013-1-18 9:46, jianhai luan wrote:> orabug: 14470382 > > When Dom0''s network environment change, for example the issue, DomU > should send send gratuitous ARP initially to notify how to reach it. > > To fix the bug, we should modify backend and frontend at the same > time. For fixing frontend, i filer the new bug 16182568. The review > only to backend. > > For fixing the backend, I have 4 patch for review.[PATCH] net/core: add NETDEV_BONDING_FAILOVER event> > Thanks, > Jason_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 2013-1-18 9:46, jianhai luan wrote:> orabug: 14470382 > > When Dom0''s network environment change, for example the issue, DomU > should send send gratuitous ARP initially to notify how to reach it. > > To fix the bug, we should modify backend and frontend at the same > time. For fixing frontend, i filer the new bug 16182568. The review > only to backend. > > For fixing the backend, I have 4 patch for review. >[PATCH]Change function netdev_bonding_change> Thanks, > Jason_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 2013-1-18 9:46, jianhai luan wrote:> orabug: 14470382 > > When Dom0''s network environment change, for example the issue, DomU > should send send gratuitous ARP initially to notify how to reach it. > > To fix the bug, we should modify backend and frontend at the same > time. For fixing frontend, i filer the new bug 16182568. The review > only to backend. > > For fixing the backend, I have 4 patch for review.[PATCH] Notify DomU to send gratuitous ARP initially by Connected->Connected transition> > Thanks, > Jason_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On 2013-1-18 9:46, jianhai luan wrote:> orabug: 14470382 > > When Dom0''s network environment change, for example the issue, DomU > should send send gratuitous ARP initially to notify how to reach it. > > To fix the bug, we should modify backend and frontend at the same > time. For fixing frontend, i filer the new bug 16182568. The review > only to backend. > > For fixing the backend, I have 4 patch for review. >The Above PATCH have been tested at some systems (Linux, Window, Solaris, NetBsd). The result is below: Linux PASS(send ARP, no other issue) Window PASS(don''t send ARP, but no other issue) Solaris PASS(don''t send ARP, but no other issue) NetBSD PASS(don''t send ARP, but no other issue)> Thanks, > Jason
Sorry, i add wrong mail address. Because the patches for review in internal oracle only, please ignore it. On 2013-1-18 10:03, jianhai luan wrote:> > On 2013-1-18 9:46, jianhai luan wrote: >> orabug: 14470382 >> >> When Dom0''s network environment change, for example the issue, DomU >> should send send gratuitous ARP initially to notify how to reach it. >> >> To fix the bug, we should modify backend and frontend at the same >> time. For fixing frontend, i filer the new bug 16182568. The review >> only to backend. >> >> For fixing the backend, I have 4 patch for review. >> > The Above PATCH have been tested at some systems (Linux, Window, > Solaris, NetBsd). The result is below: > > Linux PASS(send ARP, no other issue) > Window PASS(don''t send ARP, but no other issue) > Solaris PASS(don''t send ARP, but no other issue) > NetBSD PASS(don''t send ARP, but no other issue) > >> Thanks, >> Jason >
Because i add wrong mail address(xen-devel@lists.xensorces.com), please delete the address when you replay. I''m so sorry for your inconvenient. Thanks, Jason On 2013-1-18 10:03, jianhai luan wrote:> > On 2013-1-18 9:46, jianhai luan wrote: >> orabug: 14470382 >> >> When Dom0''s network environment change, for example the issue, DomU >> should send send gratuitous ARP initially to notify how to reach it. >> >> To fix the bug, we should modify backend and frontend at the same >> time. For fixing frontend, i filer the new bug 16182568. The review >> only to backend. >> >> For fixing the backend, I have 4 patch for review. >> > The Above PATCH have been tested at some systems (Linux, Window, > Solaris, NetBsd). The result is below: > > Linux PASS(send ARP, no other issue) > Window PASS(don''t send ARP, but no other issue) > Solaris PASS(don''t send ARP, but no other issue) > NetBSD PASS(don''t send ARP, but no other issue) > >> Thanks, >> Jason >
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. (I don''t know anything about Xen though, so I''m probably full of crap). regards, dan carpenter
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.
>>> On 18.01.13 at 11:08, Ian Campbell <Ian.Campbell@citrix.com> wrote: > However a single xenbus_printf as used here doesn''t need a transaction > since it is only a single atomic operation.Right.> 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...I don''t think so - this is just a safeguard, and I think it could as well look directly at dev->state. Jan
于 2013年01月18日 18:26, Jan Beulich 写道:>>>> On 18.01.13 at 11:08, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> However a single xenbus_printf as used here doesn't need a transaction >> since it is only a single atomic operation. > Right.If the fact is that, the code will be simple. i will modify it.> >> 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... > I don't think so - this is just a safeguard, and I think it could as > well look directly at dev->state.Right, this is just a safeguard. you think that the below way is better? if (dev->state != XenbusStateConnected) return;> > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-develThanks, Jason _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Apparently Analagous Threads
- [PATCH 2/4] pvSCSI : Fix many points of backend/frontend driver
- [PATCH 0/3] xen pvfb: Para-virtual framebuffer, keyboard and pointer
- [PATCH 0/3] xen pvfb: Para-virtual framebuffer, keyboard and pointer
- [PATCH 0/3] xen pvfb: Para-virtual framebuffer, keyboard and pointer
- [PATCH] xen-blk(front|back): Handle large physical sector disks