From owner-freebsd-stable@FreeBSD.ORG Tue Dec 4 10:23:29 2007 Return-Path: Delivered-To: stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 177CD16A468; Tue, 4 Dec 2007 10:23:29 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id CFDF913C4F2; Tue, 4 Dec 2007 10:23:28 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 16CF71CCB1; Tue, 4 Dec 2007 11:23:28 +0100 (CET) Date: Tue, 4 Dec 2007 11:23:28 +0100 From: Ed Schouten To: Robert Watson Message-ID: <20071204102328.GK72574@hoeg.nl> References: <20071203225800.S30376@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lGa3FpvTyf1CgKg0" Content-Disposition: inline In-Reply-To: <20071203225800.S30376@fledge.watson.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: stable@FreeBSD.org, current@FreeBSD.org Subject: Re: Attention 7.x and 8.x ptmx/pts users (read if you set kern.pts.enable=1) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2007 10:23:29 -0000 --lGa3FpvTyf1CgKg0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Robert Watson wrote: > 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 > 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 > way to determine that no race occurs, assuming that we implemented that. = =20 > This leakage turns out to interact particularly poorly with our resource= =20 > limits on pty/pts pairs -- both the administrative limit imposed by sysct= l=20 > and also the functional limit on the number of entries in /etc/ttys. It'= s=20 > possible to imagine various sometimes messy techniques of performing this= =20 > 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= =20 > protocol, in which eventual termination of processes referencing the node= =20 > 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 > substituted for the file descriptor of the ptmx code--similar to our mode= l,=20 > only no window between lookup and open, but also not easily supported in= =20 > our current VFS. Another possibility is to introduce a new system call a= nd=20 > 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 WWW: http://g-rave.nl/ --lGa3FpvTyf1CgKg0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHVSqf52SDGA2eCwURAlh9AJoD/Iatz0HLAjeZAZPRhWYzvNCx+wCaAkqs KoagPlubGYniKnSg4ap+ZeE= =ZzPP -----END PGP SIGNATURE----- --lGa3FpvTyf1CgKg0--