From owner-svn-src-head@freebsd.org Fri Oct 4 21:06:37 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 5DDD41396CC for ; Fri, 4 Oct 2019 21:06:37 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 46lMqx1sV7z3McR; Fri, 4 Oct 2019 21:06:37 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qt1-f174.google.com (mail-qt1-f174.google.com [209.85.160.174]) (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 17B55388A; Fri, 4 Oct 2019 21:06:37 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f174.google.com with SMTP id d16so10434071qtq.8; Fri, 04 Oct 2019 14:06:37 -0700 (PDT) X-Gm-Message-State: APjAAAXOatzcnruLrGprLfznt2Q8V7m3F42+9PTxvg7btXfaFY5gp9zg 693HCWZJZK14LhwujokPLcPzFPDfhE0jJDBktz0= X-Google-Smtp-Source: APXvYqyaebUs8+w0JDCJT0QOlSG6LSGdKZ68hZqPT5F/ZFva0HGjdRTCUG9Dbrn6Hf0PZnVKEDfyQvWqlCdO93BBN8M= X-Received: by 2002:ac8:2bf7:: with SMTP id n52mr17833110qtn.310.1570223196368; Fri, 04 Oct 2019 14:06:36 -0700 (PDT) MIME-Version: 1.0 References: <201910041343.x94Dh7Zo078270@repo.freebsd.org> In-Reply-To: From: Kyle Evans Date: Fri, 4 Oct 2019 16:06:24 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r353103 - head/sys/net To: Kyle Evans Cc: John Baldwin , 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 21:06:37 -0000 On Fri, Oct 4, 2019 at 3:48 PM Kyle Evans wrote: > > 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. Well, maybe not on that middle paragraph, but I still see no downsides. =-)