From owner-freebsd-arch@FreeBSD.ORG Wed Mar 19 18:40:24 2008 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 512FA1065671 for ; Wed, 19 Mar 2008 18:40:24 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:610:652::211]) by mx1.freebsd.org (Postfix) with ESMTP id 15F008FC1F for ; Wed, 19 Mar 2008 18:40:24 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 9211C1CC50; Wed, 19 Mar 2008 19:40:22 +0100 (CET) Date: Wed, 19 Mar 2008 19:40:22 +0100 From: Ed Schouten To: Bruce Evans Message-ID: <20080319184022.GD51074@hoeg.nl> References: <20080315124008.GF80576@hoeg.nl> <20080316015903.N39516@delplex.bde.org> <20080315194809.GN10374@deviant.kiev.zoral.com.ua> <20080316133138.J41270@delplex.bde.org> <20080319124759.GB51074@hoeg.nl> <20080320022557.K10895@besplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JwB53PgKC5A7+0Ej" Content-Disposition: inline In-Reply-To: <20080320022557.K10895@besplex.bde.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Kostik Belousov , FreeBSD Arch Subject: Re: vgone() calling VOP_CLOSE() -> blocked threads? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2008 18:40:24 -0000 --JwB53PgKC5A7+0Ej Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Bruce, * Bruce Evans wrote: > On Wed, 19 Mar 2008, Ed Schouten wrote: > >> I just changed my TTY code to perform some garbage collecting on TTY's. >> It now only performs a device cleanup when si_threadcount =3D=3D 1 and >> TF_OPENED is unset. Unfortunately, I'm checking for these conditions in >> all the cdev ops, which is quite expensive. >> >> It does the trick, but if someone has a better idea, I'm willing to >> implement it. > > When does si_threadcount go to 0 -- can it be 1 due to something other > than a cdev op holding a reference? It would probably reach 0, but because the thread calling the close routine is also taken into account, it will be 1. > If revoke() is the only problem, and if non-cdev ops can hold a > reference, then it might work to acquire a reference at the time of > the revoke. Hold this reference in some process (could even be in > userland), and consider releasing it some time later (and later again > if the synchronization hasn't completed). While this reference is > held, si_refcount cannot go to 0, so it is only necessary to check > si_threadcount =3D=3D 1 when considering releasing this reference. Because I'm not really sure about si_threadcount's locking and don't want to rely on undocumented tricks too much, I just introduced a t_threadcnt, which is adjusted when entering/leaving one of the cdev ops. This makes it a lot easier to lock as well. It should be waterproof w.r.t. referencing the TTY, but won't protect it against any open/close races yet. > New opens on the device probably need to be blocked while the state is > unsynchronized -- otherwise too many states are possible. Fortunately, the close() path doesn't block yet, but I was thinking about adding flags, which should be set when entering tricky parts of the TTY layer, such as line discipline changing and device opening and closing. For now, the current solution should suffice. I'm more worried about getting uart(4) to work right now. ;-) --=20 Ed Schouten WWW: http://g-rave.nl/ --JwB53PgKC5A7+0Ej Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkfhXhYACgkQ52SDGA2eCwVqyQCfaDvXW+AppzkoAYf0XPHVzCxH T7UAnA/PdEW5OcAfBauD/yEa+LhKVnwW =6kOC -----END PGP SIGNATURE----- --JwB53PgKC5A7+0Ej--