To: YAMAMOTO Takashi <>
From: Bill Studenmund <>
List: tech-kern
Date: 05/30/2004 19:05:37
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 31, 2004 at 02:16:02AM +0900, YAMAMOTO Takashi wrote:
> > > no.  what i asked was, why biglock is related to VOP_UPDATE while
> > > it doesn't affect VOP_GETATTR.
> >=20
> > Ahhh... Now I understand. Because VOP_GETATTR cheats. I'd rather we not=
> > have other code paths start cheating just because it does.
> cheats?  why do you think so?

Because the majority of the vnode callers and code have been very explicit=
about locking, either using the vnode lock or using the spinlock. When=20
we've found things violating the locking protocol, we've considered it a=20
bug and (usually) fixed it. Since the locks were only exclusive, you can=20
do whatever you want with the vnode.

GETATTR in this case "cheats" because it implicitly assumes that it can=20
read the inode information and get a consistent image, without grabbing a=
lock. Thus cheating.

I admit it is a rather effective "cheat" as it leaves only a small window=
open for possible corruption (were we to not have big-lock). But it's=20
still there.

Take care,


P.S. If you would indulge me with an XXX above the parts where you grab a=
shared vnode lock in your patch, I'll not object to you commiting it.=20
While I think it's wrong, your patch is no more (or less) wrong than what=
read(2) and readdir(2) are doing, and correcting what they do (i.e. making=
VOP_UPDATE take a shared or exclusive lock) will also fix your change.

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)