I've seen this issue before as well when adding RCU locking to xlate. It happens because refs to a netdev still exist (in this case, likely the tunnel has a ref to the netdev) when the main thread tries to delete the netdev. Thus, the netdev never gets deleted and the netdev cannot be recreated with a new type. I tested out the fix and it works with my patch as well.
Ryan Wilson Member of Technical Staff wr...@vmware.com 3401 Hillview Avenue, Palo Alto, CA 650.427.1511 Office 916.588.7783 Mobile On May 4, 2014, at 4:18 PM, Joe Stringer <joestrin...@nicira.com> wrote: > On 3 May 2014 02:56, Ben Pfaff <b...@nicira.com> wrote: > On Fri, May 02, 2014 at 01:13:43PM +1200, Joe Stringer wrote: > > Previously, it was possible to open a netdevice as one type, then > > proceed to open it as a different type without first closing it. The > > bridge code would expect it to be opened as the latter type and try to > > apply configuration to it. This patch catches the problem earlier by > > detecting the case in netdev_open() and logging a warning message. > > > > Bug #1198386. > > > > Signed-off-by: Joe Stringer <joestrin...@nicira.com> > > --- > > I'm not sure if this case is meant to be possible, but I've observed it, > > and this patch makes the error more obvious in the logs. > > You might want to test this against usage patterns that would try to > reuse a netdev name quickly for a different kind of device. e.g.: > > # Create myport as internal port. > ovs-vsctl add-port br0 myport -- set interface myport type=internal > > # Change myport to a tunnel. > ovs-vsctl set interface myport type=gre options:remote_ip=1.2.3.4 > > (I believe that this currently works. It should; it used to.) > > This case seems to work fine. However, if you start with two tunnel ports, > then changing the configuration for one does not always work. This appears to > be a long-standing bug. > > > A full example which I would expect to work, but doesn't: > > * ovs-vsctl add-port br0 p0 -- set int p0 type=gre options:remote_ip=1.2.3.4 > * ovs-vsctl add-port br0 p1 -- set int p1 type=internal > * ovs-vsctl set int p1 type=gre options:remote_ip=1.2.3.4 > * ovs-vsctl set int p1 type=internal > > The last step here fails: before this patch, it cannot apply gre settings to > the device (even though it is configuring to type internal). With this patch, > we see EEXIST and the error message added by this patch. For some reason, > having the other gre port around means that p1 is not completely unreferenced > before reconfiguration. Subsequently, when we reopen p1 as a different type, > we receive the original (gre) netdev. Although ovs-vsctl reflects the change > in type, the actual netdev class being used is the gre one. > > > I've proposed a fix for this bug here: > http://openvswitch.org/pipermail/dev/2014-May/039755.html > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://urldefense.proofpoint.com/v1/url?u=http://openvswitch.org/mailman/listinfo/dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=TfBS78Vw3dzttvXidhbffg%3D%3D%0A&m=av4pG3HTLdorDKsrLxxaUUZHLH%2Bm5WyoFfhanzvZx4E%3D%0A&s=867aea33cbeaee0ce83bec77ca97321a68419328a264d09bf3c60698f50f89e0
_______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
