From owner-freebsd-arch@FreeBSD.ORG Sat Mar 15 12:40:10 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 43AEA1065688 for ; Sat, 15 Mar 2008 12:40:10 +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 035928FC17 for ; Sat, 15 Mar 2008 12:40:09 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 46E6C1CC44; Sat, 15 Mar 2008 13:40:08 +0100 (CET) Date: Sat, 15 Mar 2008 13:40:08 +0100 From: Ed Schouten To: FreeBSD Arch Message-ID: <20080315124008.GF80576@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3M7QbeJEF900HlmX" Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: 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: Sat, 15 Mar 2008 12:40:10 -0000 --3M7QbeJEF900HlmX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello everyone, The last couple of days I'm seeing some strange things in my mpsafetty branch related to terminal revocation. In my current TTY design, I hold a count (t_ldisccnt) of the amount of threads that are sleeping in the line discipline. I need to store such a count, because it's not possible to change line disciplines while some threads are still blocked inside the discipline. This means that when d_close() is called on a TTY, t_ldisccnt should always be 0. There cannot be any threads stuck inside the line discipline when there aren't any descriptors referencing it. Unfortunately, this isn't entirely true with the current VFS/devfs design. When vgone() is called, a VOP_CLOSE() is performed , which means there could be a dozen threads still stuck inside a device driver, but the close routine is already called to clean up stuff. There are a *real* lot of drivers that blindly clean up their stuff in the d_close() routine, expecting that the device is completely unused. This can easily be demonstrated by revoking a bpf device, while running tcpdump. To be honest, I'm not completely sure how to solve this issue, though I know it should at least do something similar to this: - The device driver should have a seperate routine (d_revoke) to wake up any blocked threads, to make sure they leave the device driver properly. - Maybe vgonel() shouldn't call VOP_CLOSE(). It should probably move the vnode into deadfs, with the exception of the close() routine. Maybe it's better to add a new function to do this, vrevoke(). This means that when a revoke() call is performed, all blocked threads are woken up, will leave the driver, to find out their terminal has been revoked. Further system calls will fail, because the vnode is in deadfs, but when the processes close the descriptor, the device driver can still clean up everything. In theory these changes would also make it easier for other filesystems to support the revoke() call. A generic vop_revoke could just call vrevoke(), which means the current system calls aren't interrupted, but calls later on will fail. This will be sufficient for most filesystems. I'm not a VFS guru, so it will probably take me some time and will probably dogfood some of my filesystems. I could probably need some help. ;-) --=20 Ed Schouten WWW: http://g-rave.nl/ --3M7QbeJEF900HlmX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iEYEARECAAYFAkfbw6gACgkQ52SDGA2eCwWHvQCeP/wk8sTFNFsgKM2kdVhGN6PS 3zQAniPruoouxd1GnjDDq6al+rWk+pBb =zwA/ -----END PGP SIGNATURE----- --3M7QbeJEF900HlmX--