Date: Wed, 13 Feb 2019 00:04:44 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 235704] [net] [patch] tun(4) can't be destroyed on a VNET jail if it's renamed Message-ID: <bug-235704-227-c3jP2ciY9o@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-235704-227@https.bugs.freebsd.org/bugzilla/> References: <bug-235704-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=3D235704 --- Comment #3 from genneko217@gmail.com --- First, thank you so much for looking at my report. What follows is my humble analysis on the issue and my patch. Although this may be redundant or even inappropriate to include in bug reports, as a newbie, please let me summarize my thoughts. "ifconfig name destroy" issues a SIOCIFDESTROY ioctl on the interface "name", which finally calls if_clone_destroy(name) in sys/net/if_clone.c. https://svnweb.freebsd.org/base/releng/12.0/sys/net/if_clone.c?revision=3D3= 40470&view=3Dmarkup#l247 This function has two LIST_FOREACH loops which search for the 'cloner' used to create the interface "name". The first loop iterates the curvnet's cloner list and looks for a cloner whose name matches the driver name of the interface (ifp->if_dname. "tun" in this case). Because tun(4) seems to have only a single global cloner and doesn't seem to have per-VNET ones for some reason (related to the legacy devfs cloning functionality?), the cloner "tun" is not in the list and not found in the first loop. Thus the second loop is executed to look for the cloner "tun" in the global vnet0's cloner list. In the second loop, however, matching code uses the interface name (the function's argument "name". "wg0" in this case) instead of the driver name. As the interface name can be changed as seen in this report, there are cases where the second loop cannot find the cloner "tun" which is actually there. In those cases, the function exits with EINVAL, which matches the Actual Result of this report. On the other hand, a tun(4) interface on a host or non-VNET environment can be destroyed because the curvnet that the first loop iterates is the global vnet0's cloner list, which does contain the cloner "tun" and comparison is done against the driver name "tun" (not the interface name which can be changed to something like "wg0"). With those, I thought it's better for the second loop to use the same logic (comparing ifc->ifc_name with ifp->if_dname) as the first loop because the interface name (name) is changeable while the driver name (ifp->if_dname) seems not. I also noticed that with this change, it's no longer necessary to have separate matching codes depending on cloner types (SIMPLE or ADVANCED) because they are for matching full interface name including a unit number (and ADVANCED cloner even has a custom match function to handle non-starndard interface names such as epairXa/b or vlanX.Y) but now it only requires a simple, perfect match to perform lookups by driver name. --=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-235704-227-c3jP2ciY9o>