hi,

> > it says that VOP_GETATTR doesn't require the vnode locked.
> > (i think it's fine.)
> > so updating atime in VOP_READ should be protected by some
> > filesystem internal locks anyway if you want to see a consistent view of
> > timestamps without biglock. (a spinlock is enough)
> > afaik, there's no problem which was introduced by LK_SHARED for VOP_READ.
> 
> Huh? VOP_GETATTR()? I agree VOP_GETATTR() doesn't have a problem. But it's 
> not the one I have issue with, VOP_UPDATE(), which is documented to 
> require a locked vnode. That's an LK_EXCLUSIVE lock. So at present we 
> don't have any fs-internal locking.

i thought that we're talking about ITIMES.
(you mentioned about biglock and i said "atime-update".)

i don't see why VOP_UPDATE is related to biglock.
can you be more descriptive?

> > because VOP_LOCK/UNLOCK != lockmgr.
> 
> Actually it is. struct lock *v_vnlock is a pointer to a lockmgr lock, and 
> neither the new snapshotting code nor layered file systems will work if 
> it's not.

then i'd like to say it's a bug in them.
anyway it's better to (try to) keep VOP_LOCK and lockmgr different, IMO.

YAMAMOTO Takashi