--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--