From owner-freebsd-current Thu Sep 19 13:49:19 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E16F37B401 for ; Thu, 19 Sep 2002 13:49:18 -0700 (PDT) Received: from isilon.com (isilon.com [65.101.129.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id E353B43E4A for ; Thu, 19 Sep 2002 13:49:17 -0700 (PDT) (envelope-from jeffr@isilon.com) Received: from gateway.isilon.com (gateway.isilon.com [172.16.1.200]) by isilon.com (8.12.2/8.11.1) with ESMTP id g8JKnHUc092841 for ; Thu, 19 Sep 2002 13:49:17 -0700 (PDT) (envelope-from jeffr@isilon.com) Date: Thu, 19 Sep 2002 13:49:17 -0700 (PDT) From: Jeff Roberson To: current@freebsd.org Subject: Request for review & testing of VFS locking patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I have a patch available at http://www.chesapeake.net/~jroberson/vfssmp.diff that locks the majority of the vnode fields. The namecache locking has been omitted from this patch. The locking has been specified in vnode.h and all interlock, syncer, and vn lock usage has been verified. Any places that are unlocked now should be marked with mp_fixme's. This patch touches every filesystem. I have tested with several but I would appreciate more extensive testing especially if you use one of the lesser used filesystems (ie non ufs). Please test with WITNESS and DEBUG_VFS_LOCKS enabled. If you find that it drops into the debugger please get a back trace and then do the following: w vfs_badlock_panic 0 w vfs_badlock_print 0 w vfs_badlock_mutex 0 Currently I know that sendfile() and the UFS snapshot code fail assertions. There are many diffs that just switch from explicit mtx ops to using the new VI_*LOCK macros. I did this only in places where I actually reviewed the code. The remaining direct v_interlock accesses serve as indicators of behavior that needs to be further verified. I also have not verified usage of the mntvnode mtx or the freelist mutex etc. There may be racees there. I did, however, fixup the broken vflush() mntvnode race. Once this has been commited I will be free to lock the rest of the vnode and then move on to other filesystem related datastructures. My goal is to have the high level VFS and at least some filesystems SMP safe for 5.0. Any feedback is welcome. Thanks, Jeff To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message