From owner-freebsd-bugs@freebsd.org Wed Feb 13 00:04:47 2019 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1FD4914D85DC for ; Wed, 13 Feb 2019 00:04:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 82BD48B304 for ; Wed, 13 Feb 2019 00:04:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3BFB614D85DA; Wed, 13 Feb 2019 00:04:46 +0000 (UTC) Delivered-To: bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F3C9F14D85D9 for ; Wed, 13 Feb 2019 00:04:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 86B878B301 for ; Wed, 13 Feb 2019 00:04:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id A8AA8A132 for ; Wed, 13 Feb 2019 00:04:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x1D04ixv032106 for ; Wed, 13 Feb 2019 00:04:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x1D04i0g032096 for bugs@FreeBSD.org; Wed, 13 Feb 2019 00:04:44 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f 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 Date: Wed, 13 Feb 2019 00:04:44 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: genneko217@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 00:04:47 -0000 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.=