Re: crash in tmpfs_itimes since vmlocking2 merge

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Jan 24, 2008 at 12:32:59AM +0000, Andrew Doran wrote:
 > The major problem I see is that changing v_op on a live vnode is nuts,
 > particularly with the file system now being fully multithreaded. It could
 > probably be solved by adding an additonal layer of gates into VOP access.
 > Runtime cost aside that would mean understanding a bunch of complex
 > interactions.

That is a bad idea, yes.

We might get away with using atomic ops to get v_op, though. I vaguely
recall that there are platforms on which an atomic read is slow, which
might be problematic, but write speed doesn't matter in the least.

 > I would prefer to see locking pushed down to the inode level, with the file
 > system dealing with revoked vnodes.
 > [...]
 >
 > *  something like:
 > 
 > int
 > genfs_lock(vnode_t *vp, krw_t op)
 > {
 >      struct genfs_node *gp = VTOG(vp);
 > 
 >      rw_enter(&gp->g_inolock, op);
 >      if (gp->g_gone) {
 >              rw_exit(&gp->g_inolock);
 >              return EBADF;
 >      }
 >      return 0;
 > }

You could do this now with the existing vn_lock/VOP_LOCK (I think);
the only catch is that most callers of vn_lock don't check the return
value, but that's (tediously) fixable.

I think the primary problem would be that EBADF is not always the
right error. Which would get annoying to deal with.

-- 
David A. Holland
dholland%netbsd.org@localhost