On Fri, Jan 29, 1999 at 06:52:57PM -0800, Dr. Bill Studenmund wrote:
> vclean(vp)
> {
> Panic if VXLOCK1 set
> 
> Set VXLOCK & VXLOCK1
> 
> VOP_LOCK(vp, LK_DRAIN | LK_INTERLOCK | LK_CANRECURSE)
> /* The drain above wakes up all of the processes wanting this lock. They
> see VXLOCK set and thus either return errors or sleep intending to return
> an error on awake */
> 
> Clear VXLOCK  so that commands below function fine
> 
> Do all of the clean up that vclean does now
> 
> set the vnode's vnops to the deadfs ops
> 
> clear VXLOCK1, unlock the node, and awaken sleepers.

After clearing VXLOCK, you're doing some things that may put the
current process to sleep (like vinvalbuf()). Other processes may
come in and not be VXLOCK aware, i.e. they don't know that the
node is being cleaned up. This may produce unexpected results.

I think introducing a VXLOCK1 flag will just further obfuscate
things. Maybe you should look at:

	a) Do what you want to do not in VOP_CLOSE but someplace
	   else (I don't know what you want to do, though).
	b) Avoid the VOP_CLOSE or get rid of it alltogether
	   VOP_CLOSE is mainly used in an administrative fashion,
	   and also in this case VOP_INACTIVE is being called
	   immediately afterwards which makes you do these
	   administraive things twice since VOP_INACTIVE will do
	   these as well. I think NFS is even the only filesystem
	   which actually does something more in it's close vop.
	c) Make VOP_CLOSE aware of the locking and VXLOCK status.

- Frank