[Bug 185619] [VNET] Name conflict not checked when a child vnet goes away and returns its interface(s) back to the parent

From: <bugzilla-noreply_at_freebsd.org>
Date: Wed, 18 Jan 2023 21:36:16 UTC

--- Comment #5 from Kristof Provost <kp@freebsd.org> ---
(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

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.

You are receiving this mail because:
You are the assignee for the bug.