Date: Fri, 16 May 2003 22:50:04 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: tlambert2@mindspring.com Cc: current@FreeBSD.org Subject: Re: CFR: fifo_open()/fifo_close() patch Message-ID: <200305170550.h4H5o4M7059735@gw.catspoiler.org> In-Reply-To: <3EC5BFF2.9359D22F@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200305170550.h4H5o4M7059735>