ifnet renaming interacts badly with vlans

[John Baldwin]

On Friday 13 November 2009 12:44:58 pm John Baldwin wrote:
> So first the problem I am trying to solve.  I would like to give meaningful 
> aliases to interfaces and vlans on interfaces.  For example, suppose I would 
> I have em0 with a vlan of 112, but I would like to call em0, "foo" and 
> em0.112, "foo.bar".  One can do this if you do things in this order:
> 
> ifconfig em0 name foo
> ifconfig foo.112 create
> ifconfig foo.112 name foo.bar
> 
> However, our rc.d scripts want to create all cloned interfaces before applying 
> renames, so to attempt to do this in /etc/rc.conf you would use something 
> like:
> 
> cloned_interfaces="em0.112"
> ifconfig_em0_name="foo"
> ifconfig_em0_112_name="foo.bar"
> 
> However, this ends up doing a sequence more like:
> 
> ifconfig em0.112 create
> ifconfig em0 name foo
> ifconfig em0.112 name foo.bar
> 
> Unfortuantely, this sequence breaks em0.112 at the second step.  The reason is 
> that when em0 is renamed, the kernel actaully fires off event handlers 
> claiming that the em0 ifnet has been detached and that a new foo ifnet has 
> been attached.  When this happens, the em0.112 vlan ifnet is orphaned.
> 
> I think this is a bug in how renames are handled.  Specifically, I don't think 
> renaming an interface should always have the same semantics as if I had 
> physically removed an interface and then later added it back.  One 
> alternative would be to instead broadcast a single "rename" event when an 
> interface is renamed and things that cared about interface names (such as 
> firewall rules) could still honor those events, but other subsystems might 
> choose to ignore said events (e.g. vlan devices).  Another alternative might 
> be to use two different events ('ifnet_removed_name' and 'ifnet_added_name').  
> Subsystems that care about the name changing could reuse their existing 
> detached/attached handlers for those two events without needing to change the 
> event handlers themselves.  A separate issue if the eventhandlers were 
> changed is if we should use a different routing socket message when an 
> interface is renamed or if it we should still claim that an interface has 
> gone away and then come back.  Given that we don't flush addresses from an 
> interface when the name changes or even the ifindex it seems a bit 
> disingenous to claim that the interface has detached and then reattached.

So I took a more conservative approach so that the change was easier to MFC.
My current patch adds a new flag to the ifnet if_flags IFF_RENAMING that is
set during a rename operation.  ifnet attach/detach handlers can then use
this flag to handle renames differently from other events.  This means that
no other bits of code have to change to handle renames.  I then changed the
vlan(4) driver to do what I felt was most intuitive in that it renames the
child vlan interfaces if their existing name was tied to the parent
interface.

However, it turns out that this does not work well with our rc.d scripts.
Specifically, ifnet_rename() in /etc/network.subr fetches the list of devices
before any renames happen, so with the auto-renaming feature the vlan gets
renamed before the vlan interface can have its name changed.  If I remove
the auto-renaming feature then the example I gave above to rename em0.112
to foo.bar would work fine.  This is also a smaller and simpler diff to go
with this approach.  What do other folks thing?

(Current patch is http://www.FreeBSD.org/~jhb/patches/vlan_rename.patch )

-- 
John Baldwin