From owner-cvs-src@FreeBSD.ORG Tue Feb 26 12:40:38 2008 Return-Path: Delivered-To: cvs-src@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 34E9F10656F1; Tue, 26 Feb 2008 12:40:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1EEBB13C4F9; Tue, 26 Feb 2008 12:40:38 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id CD11A46B43; Tue, 26 Feb 2008 07:40:37 -0500 (EST) Date: Tue, 26 Feb 2008 12:40:37 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Konstantin Belousov In-Reply-To: <200802261010.m1QAAtgK023216@repoman.freebsd.org> Message-ID: <20080226123817.L90776@fledge.watson.org> References: <200802261010.m1QAAtgK023216@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/fs/fdescfs fdesc_vnops.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 12:40:38 -0000 On Tue, 26 Feb 2008, Konstantin Belousov wrote: > kib 2008-02-26 10:10:55 UTC > > FreeBSD src repository > > Modified files: > sys/fs/fdescfs fdesc_vnops.c > Log: > Rename fdescfs vnode from "fdesc" to "fdescfs" to avoid name collision > of the vnode lock with the fdesc_mtx mutex. Having different kinds of > locks with the same name confuses witness. I was wondering about this also--introducing locks implicitly named the same as the vnode type will cause other related problems over time. At the very least, we should be doing some name munging, I think, so that the lock name becomes foo_vnode_mtx. I realize this is somewhat complicated by the fact that WITNESS stores a pointer to the name rather than the name itself. I ran into a related problem with Coda when unloading the Coda module -- because vnodes were left around, presumably in a deadfs state, on module unload, WITNESS was panicking when it bumped into one of the locks on those vnodes as it tried to compare string names to a string in the Coda module... Robert N M Watson Computer Laboratory University of Cambridge