Subject: Re: LK_SHARED for VFS_VGET/FHTOVP
To: None <firstname.lastname@example.org>
From: YAMAMOTO Takashi <email@example.com>
Date: 05/27/2004 12:46:25
> > 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.