From owner-freebsd-current@FreeBSD.ORG Fri Dec 12 16:47:26 2003 Return-Path: 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 9853E16A4CE for ; Fri, 12 Dec 2003 16:47:26 -0800 (PST) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89DF443D53 for ; Fri, 12 Dec 2003 16:46:41 -0800 (PST) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id hBD0kTeF059375; Fri, 12 Dec 2003 16:46:33 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200312130046.hBD0kTeF059375@gw.catspoiler.org> Date: Fri, 12 Dec 2003 16:46:29 -0800 (PST) From: Don Lewis To: jroberson@chesapeake.net In-Reply-To: <20031212184001.C4201-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: kuriyama@imgsrc.co.jp cc: freebsd-current@FreeBSD.org Subject: Re: vn_fullpath: 0xc85e24a0 is not locked but should be X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Dec 2003 00:47:26 -0000 On 12 Dec, Jeff Roberson wrote: > On Fri, 12 Dec 2003, Don Lewis wrote: >> DEBUG_VFS_LOCKS is quite usable as long as you don't run find, tar, etc. >> that traverses procfs. > > This isn't entirely relevant, but I'd like to point out how happy I am > that it works even this much. When I started fixing up VFS we couldn't > even run init without DEBUG_VFS_LOCKS panicing. It took me a few weeks of > hacking to get the system running anything useful with all of these > assertions. A lot of other people have put significant effort in along > the way as well. I'm very happy to see the progress. Both of my -CURRENT machines run with DEBUG_VFS_LOCKS enabled. It is very rare that I run into problems. Doing funny things with procfs is one way to trigger assertion failures, and I think there might be a bug or two left in nullfs and/or unionfs, but I don't use those. It's probably wise to write down the proper DDB incantations to disable the code triggered by the assertion failures in case you get into trouble.