Summary: | [VNET] Name conflict not checked when a child vnet goes away and returns its interface(s) back to the parent | ||
---|---|---|---|
Product: | Base System | Reporter: | Eugene M. Kim <20080111.FreeBSD.org> |
Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
Status: | Open --- | ||
Severity: | Affects Only Me | CC: | bz, c433li, freebsd, kerio00, kp, melifaro, pat, thomas, zlei |
Priority: | Normal | ||
Version: | Unspecified | ||
Hardware: | Any | ||
OS: | Any |
Description
Eugene M. Kim
2014-01-09 22:30:00 UTC
Stumbled upon this on 11.0-RELEASE-p7, my experience matches the first scenario in the how-to-repeat perfectly. For bugs matching the following conditions: - Status == In Progress - Assignee == "bugs@FreeBSD.org" - Last Modified Year <= 2017 Do - Set Status to "Open" This seems like it might be the same issue as https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260973 (In reply to Eugene M. Kim from comment #0) > Option 2 is more predictable and deterministic, at the cost of more complex > implementation. And it doesn't cover the case of pseudo-interfaces created locally > inside a vnet, because such interfaces have no shadowed name in the parent vnet; > falling back to option 1 would be one way to solve this. For pseudo-interfaces created locally inside a vnet (n), their's `home-vnet` is same with its vnet (n) and will be destroyed on vnet destroy, so no name conflicts. I think that is a design defeat, as FreeBSD assumes the name of interface is unique in one vnet (namespace) and it allows renaming interfaces. An combination of Option 1 and Option 2: > Option 1: Give the returned interface a random, unique name. > Option 2: When injecting an interface into a child vnet, leave a "shadow" of its > name in the parent vnet. Don't let other interfaces in the parent vnet take the > shadowed name, and give the shadowed name to the moved interface when it returns > from the child vnet. I think we may give the interface a global unique unchangeable name (called xname) on create (physical or cloned ones), and refine current name as an alias and guarantee the uniqueness only within its vnet (namespace). (In practical an interface may have multiple aliases). On vnet destroy an interface returns to its home-vnet, if the alias name conflicts we can remove the alias. That may require KPI/ABI changes. Linux has similar mechanic called `altname`, see https://lwn.net/Articles/794289/ CC @kp and @melifaro (In reply to Zhenlei Huang from comment #4) I currently don't have any strong opinions on the best path to take here. My initial thought was to, on return-to-home-vnet, check for name conflicts and to rename if there was one. That's somewhat unpredictable though. On the other hand, tracking globally unique names risks significant complexity (because some interfaces are created in a vnet, i.e. not all interfaces have vnet0 as their home vnet), and also risks leaking information between vnets (i.e. vnet1 creates an epair interface, and now knows there are 5 other epairs on the system, because it got epair6a/b). That's probably not hugely important though. I will point out that I recall looking at related issues and discovering that the locking and error handling around interface renaming is either beyond me or just plain incorrect. Just encountered this issue on 14.0-RELEASE.
> Option 1: Give the returned interface a random, unique name.
Since jids are never recycled, does this approach really have to be non-deterministic? I mean, it seems to me that we could make up some sort of convention that interfaces recycled from a destroyed vnet be given a special name such as `<if_type>_recycle_<jid>`, and for hierarchical jails we can append the nested jids to it, such as `<if_type>_recycle_<jid>_<nested_jid>`.
It is still possible to have naming conflict if the user insist on renaming their interface to one of these "special" names, but this approach can eliminate the majority of these conflicts without architectural changes.
(In reply to c433li from comment #6) IFNAMSIZ is 16. That means you have no more than 15 characters for an interface name, so renaming the interface is also fraught, and also requires an additional check for conflicts after the rename. Which would also require correct lock handling (which is currently absent). This doesn't actually avoid the problem it tries to avoid. |