Date: Wed, 18 Jan 2023 21:36:16 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 185619] [VNET] Name conflict not checked when a child vnet goes away and returns its interface(s) back to the parent Message-ID: <bug-185619-227-76BL1DUwLM@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-185619-227@https.bugs.freebsd.org/bugzilla/> References: <bug-185619-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D185619 --- 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 complex= ity (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 epa= irs on the system, because it got epair6a/b). That's probably not hugely import= ant though. I will point out that I recall looking at related issues and discovering th= at the locking and error handling around interface renaming is either beyond m= e or just plain incorrect. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-185619-227-76BL1DUwLM>