svn commit: r353103 - head/sys/net
Kyle Evans
kevans at freebsd.org
Fri Oct 4 21:06:37 UTC 2019
On Fri, Oct 4, 2019 at 3:48 PM Kyle Evans <kevans at freebsd.org> wrote:
>
> On Fri, Oct 4, 2019 at 2:12 PM John Baldwin <jhb at 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. =-)
More information about the svn-src-head
mailing list