From owner-freebsd-arch@FreeBSD.ORG Wed Mar 4 23:31:48 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EBE9106564A for ; Wed, 4 Mar 2009 23:31:48 +0000 (UTC) (envelope-from matthew.fleming@isilon.com) Received: from seaxch09.isilon.com (seaxch09.isilon.com [74.85.160.25]) by mx1.freebsd.org (Postfix) with ESMTP id 838638FC0A for ; Wed, 4 Mar 2009 23:31:48 +0000 (UTC) (envelope-from matthew.fleming@isilon.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 4 Mar 2009 15:19:52 -0800 Message-ID: <06D5F9F6F655AD4C92E28B662F7F853E0275F637@seaxch09.desktop.isilon.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: knotes and force unmount Thread-Index: AcmdH7h0i1O7u+taTOGufwjpahE4rg== From: "Matthew Fleming" To: Subject: knotes and force unmount 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, 04 Mar 2009 23:31:48 -0000 At close() time knote_fdclose() will take care of any outstanding knotes for the file by looping over the list, calling kn_fop->f_detach and then knote_drop(). For a umount -f, there may still be open files; these will be handled in vgonel() by a call to VOP_CLOSE(). knotes are untouched in this case. If the filesystem is from a loadable module, then the knotes need to be cleaned up before the module is unloaded to prevent a callout into code that no longer exists, when the file is later closed. So it seems like there is code missing from vgonel() that should be doing this for the case where it calls VOP_CLOSE(). I realize this isn't a problem for ufs (never unloaded because it's used for /) and NFS (no events), but for any other filesystem this seems like a hole in the force unmount story. Is this interpretation correct? It would always be possible to add code to a filesystem's vop_close routine or its unmount routine, but architecturally this seems like something that should be handled at vgonel->VOP_CLOSE time, because it's a problem for any loadable filesystem with events. Thanks, matthew