From owner-freebsd-current@FreeBSD.ORG Mon May 19 07:37:03 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 E482437B401; Mon, 19 May 2003 07:37:03 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2EADA43F75; Mon, 19 May 2003 07:37:03 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from user-2ivfk7j.dialup.mindspring.com ([165.247.208.243] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19Hll8-0005NN-00; Mon, 19 May 2003 07:37:02 -0700 Message-ID: <3EC8EBC3.CF5BEF4E@mindspring.com> Date: Mon, 19 May 2003 07:35:47 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Don Lewis References: <200305170727.h4H7RjM7059853@gw.catspoiler.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a417007357f0024710119d90efaba1ca78666fa475841a1c7a350badd9bab72f9c350badd9bab72f9c cc: jeff@FreeBSD.org cc: current@FreeBSD.org Subject: Re: CFR: fifo_open()/fifo_close() patch 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: Mon, 19 May 2003 14:37:04 -0000 Don Lewis wrote: > On 16 May, Terry Lambert wrote: > > This is actually pretty bogus. All VOP's, except those that > > return (locked) vnodes, or dispose (locked) vnodes that are > > managed by the FS itself, should have locked vnodes. There's > > a nasty race condition that occurs because of the VOP_CLOSE() > > being called without the vnode locked. > > It does look like v_writecount is somewhat inconsistently locked. The > comment in indicates that it should be protected by the > vnode lock, but some of the INVARIANTS, DIAGNOSTIC, and KASSERT code > protects it with the vnode interlock, and vn_close() totally fails to > protect the manipulation of v_writecount. > > I'd toss in calls to vn_lock() and VOP_UNLOCK(), but it looks like while > most callers of vn_close() call it with the vnode locked, not all do. > I'm not feeling ambitious enough to track them all down. You'd have to modify a lot of FS code, as well, to do that, since they take the lock internal to the VOP_CLOSE code, in many cases. Doesn't make it any less broken, though... -- Terry