[ovs-dev] [PATCH 3/3] netdev: Warn on opening netdev as unexpected type.

Ryan Wilson wryan at vmware.com
Mon May 5 21:18:03 UTC 2014

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
wryan at 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 <joestringer at nicira.com> wrote:

> On 3 May 2014 02:56, Ben Pfaff <blp at 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 <joestringer at 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=
> (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=
> * ovs-vsctl add-port br0 p1 -- set int p1 type=internal
> * ovs-vsctl set int p1 type=gre options:remote_ip=
> * 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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20140505/fa1d7842/attachment-0005.html>

More information about the dev mailing list