From owner-freebsd-arch@FreeBSD.ORG Wed Mar 19 12:48:00 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 C15BD106566B for ; Wed, 19 Mar 2008 12:48:00 +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 8427D8FC1A for ; Wed, 19 Mar 2008 12:48:00 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id D94941CC50; Wed, 19 Mar 2008 13:47:59 +0100 (CET) Date: Wed, 19 Mar 2008 13:47:59 +0100 From: Ed Schouten To: Bruce Evans Message-ID: <20080319124759.GB51074@hoeg.nl> References: <20080315124008.GF80576@hoeg.nl> <20080316015903.N39516@delplex.bde.org> <20080315194809.GN10374@deviant.kiev.zoral.com.ua> <20080316133138.J41270@delplex.bde.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yNb1oOkm5a9FJOVX" Content-Disposition: inline In-Reply-To: <20080316133138.J41270@delplex.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 12:48:00 -0000 --yNb1oOkm5a9FJOVX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Bruce, * Bruce Evans wrote: > On Sat, 15 Mar 2008, Kostik Belousov wrote: > >> On Sun, Mar 16, 2008 at 03:55:18AM +1100, Bruce Evans wrote: >>> Other problems near here: >>> - neither vfs nor drivers currently know how many threads are in a >>> driver. vfs uses vp->v_rdev->si_usecount, but this doesn't quite work >> This is provided by si_threadcount. >> See the dev(vn)_refthread and it usage in the devfs vnops and fops. > > So why doesn't reovoke() use it? :-). All uses of si_usecount, which > normally happen via vcount() and count_dev(), are suspect, especially > the latter. > > vcount() is only used in revoke(), in svr4_fcntl.c to handle another > revoke(), and for FreeBSD < 6 in reiserfs for an old multiple-mount > check. > > count_dev() is only used in ata-tape.c (to decide in the same broken > way as vfs if a close is the last one -- this driver uses D_TRACKCLOSE > to get d_close() called on all closes. This gives it the burden of > deciding whether the close is the last one, and it can't do this any > better than vfs. D_TRACKCLOSE is used in a few other drivers which > don't call count_dev()), in devfs_close() (to decide whether to release > the controlling terminal and to decide when to call d_close()). > > Hmm, it seems to be not vfs but only devfs which handles last-close > specially. devfs is closer to devices, so it should know how to use > si_threadcount here. Hopefully si_threadcount counts threads sleeping > in open or close, although si_usecount doesn't. d_close (or something) > should be called to wake up these threads even if si_usecount is 0. > Drivers which support sleeping in open or close must support d_close > (or something) being called to forcibly end such sleeps. revoke() > should forcibly end such sleeps, so it needs to check si_threadcount > too. si_usecount in its current form might end up being unused, so > si_threadcount could be renamed back to it. 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. Thanks! --=20 Ed Schouten WWW: http://g-rave.nl/ --yNb1oOkm5a9FJOVX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkfhC38ACgkQ52SDGA2eCwWzhQCZAfkFEA+m0cZVS4782P9Bwnot r3YAn3oGxzHPffeV0t+wxKHzTuGIdcSh =XhOz -----END PGP SIGNATURE----- --yNb1oOkm5a9FJOVX--