From owner-svn-src-head@freebsd.org Fri Oct 4 20:49:12 2019 Return-Path: Delivered-To: svn-src-head@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 0C1C7138E1E for ; Fri, 4 Oct 2019 20:49:12 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46lMRq6T2fz3LNb; Fri, 4 Oct 2019 20:49:11 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id B506A34AF; Fri, 4 Oct 2019 20:49:11 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f178.google.com with SMTP id z67so7034674qkb.12; Fri, 04 Oct 2019 13:49:11 -0700 (PDT) X-Gm-Message-State: APjAAAXlJ6/I4ac8HZ7gzA85tDc99QigDSr5i6Rm7Lr5K39bX4tBNIvO XRCOWz6lXK4edy0WWc/+zq4QZOml4Gwh8mnV1M8= X-Google-Smtp-Source: APXvYqysePR8U+dN8HEdU+bmQPVXpgbxe26q7IwCRHyQg9PSvqhARoCUw8JsyUjz3mmQd9MgQ5gLUEkEho5DC/HWYK4= X-Received: by 2002:a37:7d04:: with SMTP id y4mr11271742qkc.34.1570222151308; Fri, 04 Oct 2019 13:49:11 -0700 (PDT) MIME-Version: 1.0 References: <201910041343.x94Dh7Zo078270@repo.freebsd.org> In-Reply-To: From: Kyle Evans Date: Fri, 4 Oct 2019 15:48:59 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r353103 - head/sys/net To: John Baldwin Cc: src-committers , svn-src-head Content-Type: text/plain; charset="UTF-8" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 20:49:12 -0000 On Fri, Oct 4, 2019 at 2:12 PM John Baldwin wrote: > > On 10/4/19 6:43 AM, Kyle Evans wrote: > > Author: kevans > > Date: Fri Oct 4 13:43:07 2019 > > New Revision: 353103 > > URL: https://svnweb.freebsd.org/changeset/base/353103 > > > > Log: > > tuntap(4): loosen up tunclose restrictions > > > > Realistically, this cannot work. We don't allow the tun to be opened twice, > > so it must be done via fd passing, fork, dup, some mechanism like these. > > Applications demonstrably do not enforce strict ordering when they're > > handing off tun devices, so the parent closing before the child will easily > > leave the tun/tap device in a bad state where it can't be destroyed and a > > confused user because they did nothing wrong. > > > > Concede that we can't leave the tun/tap device in this kind of state because > > of software not playing the TUNSIFPID game, but it is still good to find and > > fix this kind of thing to keep ifconfig(8) up-to-date and help ensure good > > discipline in tun handling. > > Why are you using d_close for last close anyway? It's not really reliable compared > to using cdevpriv and a cdevpriv dtor. > This decision predates me by a long time, I'm afraid. =-) If you have time to elaborate on the comparable reliability point, I'd be interested in hearing it. A little bit of searching didn't seem to turn up much there, I'm afraid. I did otherwise spend a little bit of time diving into the path taken to get to d_close and the trade-offs between cdevpriv vs. what tuntap does now. I think I'm convinced either way that cdevpriv is a good way to go- it seems to have the advantage that with a little refactoring we could actually set the softc atomically on the device cdevpriv instead of cdev->si_drv1 and I can axe this rwatson@ comment about the non-atomic test and set. I don't see any downside here.