Re: Attention 7.x and 8.x ptmx/pts users (read if you set kern.pts.enable=1)

2007-12-05 Thread Ed Schouten
* Ed Schouten [EMAIL PROTECTED] wrote: 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 just saw a commit flash by that disables si_cred usage in make_dev_cred(). That is indeed a good

Re: Attention 7.x and 8.x ptmx/pts users (read if you set kern.pts.enable=1)

2007-12-04 Thread Ed Schouten
* Robert Watson [EMAIL PROTECTED] 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

Re: Attention 7.x and 8.x ptmx/pts users (read if you set kern.pts.enable=1)

2007-12-04 Thread Robert Watson
On Tue, 4 Dec 2007, Ed Schouten wrote: * Robert Watson [EMAIL PROTECTED] 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

Re: Attention 7.x and 8.x ptmx/pts users (read if you set kern.pts.enable=1)

2007-12-04 Thread Ed Schouten
* Robert Watson [EMAIL PROTECTED] wrote: Yes. There's also another known issue, likely not corrected by this patch, in which closing the pty before the pts fails to properly wake up processes hung off the pts and inform them of its impending doom, resulting in the pty/pts pair never being

Attention 7.x and 8.x ptmx/pts users (read if you set kern.pts.enable=1)

2007-12-03 Thread Robert Watson
(If you aren't interested in the details of our ptmx/pty/pts driver, skip to the paragraph that reads So, why the long-winded story?) Dear all: The current ptmx/pts implementation makes use of devfs(4) cloning: a user process wanting to allocate a pty/pts pair opens /dev/ptmx, which returns