Module Name:	src
Committed By:	gdt
Date:		Sun Apr  8 00:21:59 UTC 2007

Modified Files:
	src/sys/coda: coda_vnops.c

Log Message:
Further cleanups on coda vnode handling.

Re-enable mmap.  The problem is how uvm_fault handles page faults from
coda vnodes via container files, and executing a program caused the
same problem so disabling mmap only helped cp(1).

coda_open:
  rename variables to match vnode_if.src
  better comments about lock/reference state of vnodes
  keep lock on container file until after VOP_OPEN, which requires locked vp
  remove #if 0'd code to PNBUF_PUT

coda_link:
  rename variables to match vnode_if.src
  error out early if vp == dvp
  check return value on vn_lock, and add comment questoining the lock
  clarify lock handling, but unchanged logic
  remove #if 0'd code to PNBUF_PUT

coda_rmdir:
  error out early if vp == dvp
  remove #if 0'd code to PNBUF_PUT

coda_grab_vnode:
  add comments, and in particular question undocumented VFS_VGET semantics

coda_getpages:
  question calling VOP_OPEN, which requires a locked vnode, with the
  vnode we got (vop_getpages does not guarantee a locked vnode)

coda_putpages:
  remove inexplicable simple_unlock(&vp->v_interlock);
  add printf so we notice if this is ever called

  add comment explaining that the implementation will lead to trouble,
  because vnode_if.src says putpages is called with v_uobj.vmobjlock
  held and is supposed to unlock it

With these changes and an uncommitted change to uvm_fault not to panic
if uvm objects are not equal, coda seems stable again.


To generate a diff of this commit:
cvs rdiff -r1.54 -r1.55 src/sys/coda/coda_vnops.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.