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

Joe Stringer joestringer at nicira.com
Sun May 4 23:18:50 UTC 2014


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=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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20140505/a9cfd53e/attachment-0005.html>


More information about the dev mailing list