On 8/1/12 2:41 PM, Hans Petter Selasky wrote:
On Wednesday 01 August 2012 22:46:58 Ed Schouten wrote:
Hi Kostik,
2012/8/1 Konstantin Belousov <kostik...@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.
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.
I think that the /dev/entries can (and SHOULD) go away when the hardware
goes away and even be re-used.
The devfs entry is after all just a name..
it's the underlying parts (the bottom of the iceberg) that needs to
stay to
handle calls from file descriptors that are still open and THAT
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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
