From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 22:47:38 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 D8465106566B for ; Wed, 1 Aug 2012 22:47:38 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id A189C8FC12 for ; Wed, 1 Aug 2012 22:47:38 +0000 (UTC) Received: from JRE-MBP-2.local (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id q71MlPfs086283 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 1 Aug 2012 15:47:26 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5019B1F8.5080802@freebsd.org> Date: Wed, 01 Aug 2012 15:47:20 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Hans Petter Selasky References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> <201208012341.25509.hselasky@c2i.net> In-Reply-To: <201208012341.25509.hselasky@c2i.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , Ed Schouten , freebsd-current@freebsd.org 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 22:47:39 -0000 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 : >>> 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-unsubscribe@freebsd.org" > >