Re: ttydev_cdevsw has no d_purge

On Wednesday 01 August 2012 22:46:58 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?
> 
> 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_at_ numerous
> times. It simply must not do that.

Hi Ed & Others,

I think the problem is like this, that in order to re-use the unit numbers for 
USB serial tty devices, the USB stack needs to wait until a TTY is actually 
freed, right? Else you will have a panic on creating devfs entries having the 
same name.

For /dev/usb/XXX nodes the USB stack supports that the client and dynamic 
kernel USB device structures can be separated at any time. I think Andrew 
Thompson was part of that design, that we allocate a small structure 
containing some information that allows us to quickly _lookup_ the USB kernel 
device at every read/write/ioctl/whatever, and then we simply mark the so-
called cdev_priv invalid in case of detach, and it is actually freed when the 
fd is closed, while the kernel structures go away immediately. I think this 
same approach must be taken inside the TTY layer. I'm not sure how easy this 
will be, though.

--HPS