From owner-freebsd-bugs@freebsd.org Mon Dec 23 20:08:45 2019 Return-Path: Delivered-To: freebsd-bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C699C1CF406 for ; Mon, 23 Dec 2019 20:08:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 47hVmF4wVRz40gv for ; Mon, 23 Dec 2019 20:08:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id A6FBD1CF403; Mon, 23 Dec 2019 20:08:45 +0000 (UTC) Delivered-To: bugs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A580B1CF402 for ; Mon, 23 Dec 2019 20:08:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::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.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47hVmF3kyVz40gt for ; Mon, 23 Dec 2019 20:08:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7BBC21CE96 for ; Mon, 23 Dec 2019 20:08:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id xBNK8jPN022012 for ; Mon, 23 Dec 2019 20:08:45 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id xBNK8jiX022011 for bugs@FreeBSD.org; Mon, 23 Dec 2019 20:08:45 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 242841] Unkillable process when attempting to destroy an open tun device Date: Mon, 23 Dec 2019 20:08:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: cperciva@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: 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: Mon, 23 Dec 2019 20:08:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D242841 Bug ID: 242841 Summary: Unkillable process when attempting to destroy an open tun device Product: Base System Version: 12.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: cperciva@FreeBSD.org This is admittedly partly a case of "don't do that" (I tripped over it due = to a bug in code I was writing), but it seems like the kernel should handle it a= bit more gracefully. If you: 1. Create a tun device (via SIOCIFCREATE), 2. Open the tun device (via open("/dev/tun#")), and then 3. Attempt to destroy the tun device (via SIOCIFDESTROY), the SIOCIFDESTROY ioctl will block on tun_condvar until the last file descriptor holding the device open has been closed. Generally sensible... except that the file descriptor in question is owned by the process which called the ioctl, and it's stuck inside the kernel now and will never be ab= le to close the device. This results in a process which cannot be killed. A better solution might be to detect when the process calling SIOCIFDESTROY= is the same as the process which owns the tunnel device, and return an error (maybe EBUSY) rather than blocking indefinitely. --=20 You are receiving this mail because: You are the assignee for the bug.=