tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: crash in tmpfs_itimes since vmlocking2 merge

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

Home | Main Index | Thread Index | Old Index