Date: Tue, 17 Sep 2002 07:27:35 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Don Lewis <dl-freebsd@catspoiler.org> Cc: arch@FreeBSD.org, Ian Dowse <iedowse@maths.tcd.ie> Subject: Re: VOP_INACTIVE() Message-ID: <3D873BD7.35610322@mindspring.com> References: <200209171031.g8HAV5wr015790@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Don Lewis wrote: > The first fix is to set a flag on the vnode to indicate that > VOP_INACTIVE() is playing with the vnode, so the vnode should not be > reused even though its reference count is zero. This is what used to happen; the flag was V_LOCK (or something like that). There were a couple of instances of inversion in its use, and it was hard to keep straight. > The second fix is to all VOP_INACTIVE() before the reference count is > decremented. The main problem with this is that some of the things done > in the various filesystem inactive methods may depend strongly on the > reference count being zero. One example is the call to vrecycle() in > ufs_inactive(). > > A third fix would be to split VOP_INACTIVE() into two parts, one which > is called to do any I/O before the reference count is decremented, and > the other which does any filesystem specific cleanup after the reference > count is decremented. > > Opinions? I do not like the third option. The logical thing to do would be to not assume anything about the reference count, and that VOP_INACTIVE() *means* VOP_INACTIVE(). This is a modification of the second option. Obviously, you do not want to drop the reference in the higher level code, until you are certain the the reference has been dropped by the lower level code. The real issue here is that the VOP_INACTIVE() is a "give the vnode back to the system" operation, and gives proxy ownership of the vnode the the VFS. This is right. What's wrong is that the vnode that comes out does not have a reference which is owned by the VFS. If this is corrected, you can call VOP_INACTIVE(), and expect that the reference count will be decremented, and that ownership of the vnode will *not* necessarily pass back to the system. The way this works is to set up a reference count management via procedure call, making this a procedural interface. This would be a system function (e.g.: "grab a vnode, get a vnode with a reference count of one back, dispose a vnode of reference count 1, and have the 1->0 transition free the vnode back to the system). For this to really work, open instances need to be references... and directory cache instances *also* need t be references. This is easier, if you think of vnode ownership being with the file system, instead of with the OS, and that the OS-wide pool is really nothing more than a memory manager implementation detail for the vnode structure allocation and free. The TFS vnode references are a good example for this, if they are still around, because in the TFS code, the vnode *was* owned and managed by the VFS (the same would be true for any vnodes for binary SVR4 or other VFS modules that were run in a FreeBSD environment, FWIW). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D873BD7.35610322>