Attention 7.x and 8.x ptmx/pts users (read if you set
kern.pts.enable=1)
Ed Schouten
ed at fxq.nl
Tue Dec 4 02:23:29 PST 2007
* Robert Watson <rwatson at FreeBSD.org> wrote:
> Unfortunately, the current implementation is subject to a potential
> resource leak: the pty is created when the lookup occurs, but if the open
> never takes place, then the pty is leaked. In principle, we have
> facilities to GC unused device nodes "eventually", although not a race-free
> way to determine that no race occurs, assuming that we implemented that.
> This leakage turns out to interact particularly poorly with our resource
> limits on pty/pts pairs -- both the administrative limit imposed by sysctl
> and also the functional limit on the number of entries in /etc/ttys. It's
> possible to imagine various sometimes messy techniques of performing this
> 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')?
> Instead, what I'd like to do is modify the ptmx code to have a race-free
> protocol, in which eventual termination of processes referencing the node
> results in freeing of the nodes. On some systems, ptmx performs a
> "bait-and-switch", in which the file descriptor of the pty node is silently
> substituted for the file descriptor of the ptmx code--similar to our model,
> only no window between lookup and open, but also not easily supported in
> our current VFS. Another possibility is to introduce a new system call and
> 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.
--
Ed Schouten <ed at fxq.nl>
WWW: http://g-rave.nl/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20071204/bcac58f8/attachment.pgp
More information about the freebsd-current
mailing list