Date: Sat, 30 Sep 2006 05:53:58 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Martin Blapp <mb@imp.ch> Cc: cvs-src@FreeBSD.org, Martin Blapp <mbr@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/kern tty_pty.c Message-ID: <20060930044711.H96144@delplex.bde.org> In-Reply-To: <20060929202338.W91466@godot.imp.ch> References: <200609290952.k8T9qvcU053566@repoman.freebsd.org> <20060929202338.W91466@godot.imp.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 29 Sep 2006, Martin Blapp wrote: >> Free tty struct after last close. This should fix the pty-leak by numbers. >> Remove workarounds for tty_refcount beeing 0, this will be fixed >> differently >> later. >> >> Back out rev 1.145 since we initialize the tty struct from scratch and bad >> things can't happen anymore. > > Sigh. Peter Holmes stress tests did show that we still have problems. With > the beckout of rev. 1.145 we get again the same panics as the pty_pts code > does. > This is deep somewhere in the devfs code. It does happen with/without freeing > struct tty. > > Memory modified after free 0xc45b7d00(252) val=deadc0dd @ 0xc45b7d70 > panic: Most recently used by DEVFS1 > ... I think I found the bug while looking for problems near vgonel(). We're nowhere near ready to free devices in in last-close, since vgonel() doesn't do anything to evict processes from device functions before it forces the device closed. Drivers must be aware of the problem. The tty driver already is. See the comments about t_gen near tty_close() and ttysleep(). t_gen must live across close so that any processes in device functions can check it after they wake up, and the tty and device data structures must live across last- close to hold t_gen and anything else needed for the device functions to return. Sleeping device functions normally wake up after last-close returns. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060930044711.H96144>