Date: Wed, 1 Aug 2012 22:46:58 +0200 From: Ed Schouten <ed@80386.nl> To: Konstantin Belousov <kostikbel@gmail.com> Cc: current@freebsd.org Subject: Re: ttydev_cdevsw has no d_purge Message-ID: <CAJOYFBDsK8cZYc28sKcC0qcZrpy2=A3QAHvP5fEj9gn=Acwciw@mail.gmail.com> In-Reply-To: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Kostik, 2012/8/1 Konstantin Belousov <kostikbel@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? In the current design, the USB code must call into tty_gone() to 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. 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@ numerous times. It simply must not do that. -- Ed Schouten <ed@80386.nl>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJOYFBDsK8cZYc28sKcC0qcZrpy2=A3QAHvP5fEj9gn=Acwciw>