From owner-cvs-src@FreeBSD.ORG Tue Mar 15 13:28:11 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 107BB16A4CE; Tue, 15 Mar 2005 13:28:11 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8439243D49; Tue, 15 Mar 2005 13:28:10 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id j2FDS9d4042950; Tue, 15 Mar 2005 08:28:09 -0500 (EST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)j2FDS9O4042945; Tue, 15 Mar 2005 08:28:09 -0500 (EST) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Tue, 15 Mar 2005 08:28:09 -0500 (EST) From: Jeff Roberson To: Jeff Roberson In-Reply-To: <200503151128.j2FBSj9D054456@repoman.freebsd.org> Message-ID: <20050315082516.U20708@mail.chesapeake.net> References: <200503151128.j2FBSj9D054456@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/fs/nullfs null_vnops.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Mar 2005 13:28:11 -0000 On Tue, 15 Mar 2005, Jeff Roberson wrote: > jeff 2005-03-15 11:28:45 UTC > > FreeBSD src repository > > Modified files: > sys/fs/nullfs null_vnops.c > Log: > - We have to transfer lockers after reseting our vnlock pointer. Upon further review, this is wrong, but the code that was there before was wrong too. The problem is that if we transferlockers we may transfer threads that are legitimately waiting on the ufs lock rather than the null lock. I believe the solution is to reset our lock, but allow callers to naturally return out of the ufs lock routine when they're ready. The vnode reference count will prevent anything from going away while we're stuck in ufs's locking function. > > Sponsored by: Isilon Systems, Inc. > > Revision Changes Path > 1.84 +5 -0 src/sys/fs/nullfs/null_vnops.c >