From owner-freebsd-current@FreeBSD.ORG Tue Dec 4 11:47:25 2007 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CD0F16A417; Tue, 4 Dec 2007 11:47:25 +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 606FD13C455; Tue, 4 Dec 2007 11:47:25 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 9D3DE1CCCE; Tue, 4 Dec 2007 12:47:24 +0100 (CET) Date: Tue, 4 Dec 2007 12:47:24 +0100 From: Ed Schouten To: Robert Watson Message-ID: <20071204114724.GL72574@hoeg.nl> References: <20071203225800.S30376@fledge.watson.org> <20071204102328.GK72574@hoeg.nl> <20071204111050.W30376@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Y8IEA2AKDLXNckrV" Content-Disposition: inline In-Reply-To: <20071204111050.W30376@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-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Dec 2007 11:47:25 -0000 --Y8IEA2AKDLXNckrV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Robert Watson wrote: > Yes. There's also another known issue, likely not corrected by this patc= h,=20 > in which closing the pty before the pts fails to properly wake up process= es=20 > hung off the pts and inform them of its impending doom, resulting in the= =20 > pty/pts pair never being garbage-collected. I've not tracked this down= =20 > yet, but you can reproduce it by running screen(1) and then "killing" a= =20 > screen. screen(1) closes the pty and relies on the pty/pts mechanism to = do=20 > the rest, which doesn't. Indeed. I also noticed this bug. Simply killing sshd also reproduces this. The leak is caused by the obvious if-statement inside pty_maybecleanup(). This is because SESSRELE() is called after sshd closes the pty, if I can remember correctly. This also causes the dreaded `jail leak', because device nodes still exist that have been created with make_dev_cred(), so the ucred is still referenced. I guess the problem is that we can only call pty_maybecleanup() when ptsclose() is called and not when the real use-count of the tty has reached zero. Yours, --=20 Ed Schouten WWW: http://g-rave.nl/ --Y8IEA2AKDLXNckrV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFHVT5M52SDGA2eCwURAuVmAJ4+IKFmjDtwN6FE3rpxbfX5Vrz5DwCeLMyJ Bwo1kNdbwesN2pzbYGpAUXc= =FNK+ -----END PGP SIGNATURE----- --Y8IEA2AKDLXNckrV--