Re: ttydev_cdevsw has no d_purge

On Wed, Aug 01, 2012 at 10:46:58PM +0200, Ed Schouten wrote:
> Hi Kostik,
> 
> 2012/8/1 Konstantin Belousov <kostikbel_at_gmail.com>:
> > I would blame tty subsystem rather then USB subsystem.  The d_purge
> > method of the ttydev_cdevsw is not implemented, but it is the only
> > measure that can break the deadlocks like the one I described. The
> > d_purge shall wake up threads sleeping inside devsw methods, which was
> > specifically added to notify driver about device gone events.
> 
> I guess d_purge was added quite recently, right?
No, it was there at least in 2006. In fact, it seems to be added in 2004,
see r135843.

> 
> In the current design, the USB code must call into tty_gone() to
You mean tty_rel_gone(), right ?

> report that the TTY is no longer associated with an actual device.
> This shall result in all threads blocking on a TTY to be woken up.
> Also, it will prevent any further calls into the USB code by the TTY
> layer.
> 
> Still, if the processes are not actually interacting with the TTY
> (e.g. sleep 100000, just waiting for nanosleep() to return), then
> there is no way the TTY code can actually garbage collect the TTY. It
> must stay there. Removing the actual TTY would introduce a whole bunch
> of races and unwanted behaviour. Applications may cache the pathname
> to the TTY. If the pathname were to be reused by another device, apps
> would start writing to random TTYs. So that's why TTYs may still stick
> around in devfs, even though the device underneath went missing. The
> driver simply calls tty_gone() and leaves the TTY alone. It will die
> eventually, but you shouldn't wait for it to happen.
Well, IMO it is weird, and tty should be destroyed immediately. Do
we have any problems with pts-style pty which would force reuse of
device names ? For hardware ttys, immediate removal looks just right
unconditionally.

> 
> Still, I seem to remember the USB code does something weird. I think
> the USB serial driver tries to block until the TTY is actually
> destroyed. This is a bug, which I've discussed with hselasky_at_ numerous
> times. It simply must not do that.
Yes, it does. ucom_detach_tty():
		tty_rel_gone(tp);
		mtx_lock(sc->sc_mtx);
		/* Wait for the callback after the TTY is torn down */
		while (sc->sc_ttyfreed == 0)
			cv_wait(&sc->sc_cv, sc->sc_mtx);
and  sc_ttyfreed is set from destroy_dev_sched callback.