Date: Fri, 4 Oct 2019 12:11:58 -0700 From: John Baldwin <jhb@FreeBSD.org> To: Kyle Evans <kevans@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r353103 - head/sys/net Message-ID: <ece67d32-2624-4e06-08a6-5d67aa4a2e03@FreeBSD.org> In-Reply-To: <201910041343.x94Dh7Zo078270@repo.freebsd.org> References: <201910041343.x94Dh7Zo078270@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ece67d32-2624-4e06-08a6-5d67aa4a2e03>