Subject: Re: LK_SHARED for VFS_VGET/FHTOVP
To: YAMAMOTO Takashi <email@example.com>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 05/30/2004 19:05:37
Content-Type: text/plain; charset=us-ascii
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.
> > 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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----