--aVD9QWMuhilNxW9f
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=
=20
> > have other code paths start cheating just because it does.
>=20
> cheats?  why do you think so?

Because the majority of the vnode callers and code have been very explicit=
=20
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=
=20
lock. Thus cheating.

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

Take care,

Bill

P.S. If you would indulge me with an XXX above the parts where you grab a=
=20
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=
=20
read(2) and readdir(2) are doing, and correcting what they do (i.e. making=
=20
VOP_UPDATE take a shared or exclusive lock) will also fix your change.

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFAupLxWz+3JHUci9cRAjTlAJ4hbaq8e5h6CG1a/wZ1yMD5M/2XfACglEHr
pnYfu+oCRNXROxoYBvYO398=
=upI8
-----END PGP SIGNATURE-----

--aVD9QWMuhilNxW9f--