Date: Fri, 4 Oct 2019 16:06:24 -0500 From: Kyle Evans <kevans@freebsd.org> To: Kyle Evans <kevans@freebsd.org> Cc: John Baldwin <jhb@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r353103 - head/sys/net Message-ID: <CACNAnaF%2B97=ypRyK04%2B5P%2BchzsCr4h98jbwYk950htnEEVTuLA@mail.gmail.com> In-Reply-To: <CACNAnaG-cbK6VtJA1S6_zL7M=QpTwBS6WytbJLjK71yZOsBgBA@mail.gmail.com> References: <201910041343.x94Dh7Zo078270@repo.freebsd.org> <ece67d32-2624-4e06-08a6-5d67aa4a2e03@FreeBSD.org> <CACNAnaG-cbK6VtJA1S6_zL7M=QpTwBS6WytbJLjK71yZOsBgBA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 4, 2019 at 3:48 PM Kyle Evans <kevans@freebsd.org> wrote: > > On Fri, Oct 4, 2019 at 2:12 PM John Baldwin <jhb@freebsd.org> 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. =-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaF%2B97=ypRyK04%2B5P%2BchzsCr4h98jbwYk950htnEEVTuLA>