* Robert Watson <rwatson@FreeBSD.org> wrote:
quoted text
> Unfortunately, the current implementation is subject to a potential=20
> resource leak: the pty is created when the lookup occurs, but if the open=
=20
quoted text
> never takes place, then the pty is leaked.  In principle, we have=20
> facilities to GC unused device nodes "eventually", although not a race-fr=
ee=20
quoted text
> way to determine that no race occurs, assuming that we implemented that. =
=20
quoted text
> This leakage turns out to interact particularly poorly with our resource=
=20
quoted text
> limits on pty/pts pairs -- both the administrative limit imposed by sysct=
l=20
quoted text
> and also the functional limit on the number of entries in /etc/ttys.  It'=
s=20
quoted text
> possible to imagine various sometimes messy techniques of performing this=
=20
quoted text
> garbage collection.

So this is the same issue I sent a message to arch@ about some time ago,
that /dev/ptmx already returns a reference to the new pty, already when
you stat(2) it (for example by running `ls -l /dev/ptmx')?

quoted text
> Instead, what I'd like to do is modify the ptmx code to have a race-free=
=20
quoted text
> protocol, in which eventual termination of processes referencing the node=
=20
quoted text
> results in freeing of the nodes.  On some systems, ptmx performs a=20
> "bait-and-switch", in which the file descriptor of the pty node is silent=
ly=20
quoted text
> substituted for the file descriptor of the ptmx code--similar to our mode=
l,=20
quoted text
> only no window between lookup and open, but also not easily supported in=
=20
quoted text
> our current VFS.  Another possibility is to introduce a new system call a=
nd=20
quoted text
> bypass ptmx entirely -- similar to pipe(), socketpair(), etc.

I actually think that this sounds pretty nice. You mean something like
an in-kernel implementation for openpty()?

Another thing that would make the TTY code a little bit cleaner in my
opinion is removing the PRIV_TTY_PRISON check and making something
generic inside devfs. If we have proper garbage collecting on TTY's,
then we can just change make_dev_cred() to bind the new device node to a
certain jail. That way you could even choose to hide nodes in /dev that
don't belong to the jail in question.

--=20
 Ed Schouten <ed@fxq.nl>
 WWW: http://g-rave.nl/