From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 21:41:10 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EB8351065672 for ; Wed, 1 Aug 2012 21:41:10 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.c2i.net [212.247.154.162]) by mx1.freebsd.org (Postfix) with ESMTP id 776EE8FC12 for ; Wed, 1 Aug 2012 21:41:10 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.212.201] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe06.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 302371102; Wed, 01 Aug 2012 23:41:03 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 1 Aug 2012 23:41:25 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@d2+AyewRX}mAm; Yp |U[@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y>Y}k1C4TfysrsUI -%GU9V5]iUZF&nRn9mJ'?&>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201208012341.25509.hselasky@c2i.net> Cc: Konstantin Belousov , Ed Schouten Subject: Re: ttydev_cdevsw has no d_purge X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 21:41:11 -0000 On Wednesday 01 August 2012 22:46:58 Ed Schouten wrote: > Hi Kostik, > > 2012/8/1 Konstantin Belousov : > > 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. 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