From owner-freebsd-current@FreeBSD.ORG Wed Aug 1 21:02:17 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0488C106564A; Wed, 1 Aug 2012 21:02:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 7ACA78FC0C; Wed, 1 Aug 2012 21:02:16 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q71L2NKr058655; Thu, 2 Aug 2012 00:02:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q71L2Al1075890; Thu, 2 Aug 2012 00:02:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q71L2AZG075889; Thu, 2 Aug 2012 00:02:10 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 2 Aug 2012 00:02:10 +0300 From: Konstantin Belousov To: Ed Schouten Message-ID: <20120801210210.GU2676@deviant.kiev.zoral.com.ua> References: <20120801160323.GN2676@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ilwtao6+P+Teod98" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: current@freebsd.org, hselasky@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 21:02:17 -0000 --ilwtao6+P+Teod98 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 01, 2012 at 10:46:58PM +0200, Ed Schouten wrote: > Hi Kostik, >=20 > 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. >=20 > I guess d_purge was added quite recently, right? No, it was there at least in 2006. In fact, it seems to be added in 2004, see r135843. >=20 > In the current design, the USB code must call into tty_gone() to You mean tty_rel_gone(), right ? > 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. >=20 > 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. Well, IMO it is weird, and tty should be destroyed immediately. Do we have any problems with pts-style pty which would force reuse of device names ? For hardware ttys, immediate removal looks just right unconditionally. >=20 > 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. Yes, it does. ucom_detach_tty(): tty_rel_gone(tp); mtx_lock(sc->sc_mtx); /* Wait for the callback after the TTY is torn down */ while (sc->sc_ttyfreed =3D=3D 0) cv_wait(&sc->sc_cv, sc->sc_mtx); and sc_ttyfreed is set from destroy_dev_sched callback. --ilwtao6+P+Teod98 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlAZmVIACgkQC3+MBN1Mb4g/bgCg8E/RDnksdoqCy4SZF1CEdDkC KbkAoOZ5UeKLTqcn4cZ1EtEwl7GRKYxa =uxK2 -----END PGP SIGNATURE----- --ilwtao6+P+Teod98--