From owner-freebsd-current@FreeBSD.ORG  Fri May 16 22:50:13 2003
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 9C7A637B401
	for <current@FreeBSD.org>; Fri, 16 May 2003 22:50:13 -0700 (PDT)
Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 3A15B43F3F
	for <current@FreeBSD.org>; Fri, 16 May 2003 22:50:12 -0700 (PDT)
	(envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.12.9/8.12.9) with ESMTP id h4H5o4M7059735;
	Fri, 16 May 2003 22:50:08 -0700 (PDT)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <200305170550.h4H5o4M7059735@gw.catspoiler.org>
Date: Fri, 16 May 2003 22:50:04 -0700 (PDT)
From: Don Lewis <truckman@FreeBSD.org>
To: tlambert2@mindspring.com
In-Reply-To: <3EC5BFF2.9359D22F@mindspring.com>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
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
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 17 May 2003 05:50:13 -0000

On 16 May, Terry Lambert wrote:
> 
> 
> Don Lewis wrote:
>> 
>> There are a few problems in the fifo_open() and fifo_close()
>> implementations.
>> 
>>         fifo_open() calls VOP_CLOSE() with the vnode locked, whereas
>>         VOP_CLOSE() should be called with the vnode unlocked.
> 
> 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.

Well, that's what is presently implemented.

If you close a file descriptor in userland, eventually you end up in
vn_closefile(), which calls
	vn_close(fp->f_data, fp->f_flag, fp->f_cred, td)
where fp->f_data is the vnode, and vn_close() calls VOP_CLOSE() without
locking the vnode.  VOP_CLOSE() is called one other place in
vfs_vnops.c, and there the vnode is explicitly unlocked before calling
VOP_CLOSE().

vnode_if.src documents VOP_CLOSE() as wanting the vnode to be unlocked
on entry and exit.