--HeFlAV5LIbMFYYuh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 19, 2004 at 06:17:15AM +0000, YAMAMOTO Takashi wrote:
>=20
> Module Name:	src
> Committed By:	yamt
> Date:		Sat Jun 19 06:17:15 UTC 2004
>=20
> Modified Files:
> 	src/sys/miscfs/genfs: layer_vnops.c
>=20
> Log Message:
> layer_islocked: check a status of the lower vnode as well.

Actually I think it is about time we rip out the shadow locking that
layered file systems are doing. When it was added, a number of file
systems (nfs, kernfs, procfs) didn't do real node locking; they used
genfs_nolock(). Now there are very few uses of genfs_nolock(), so I think
we can just remove it.

The only users I still see are:

spec_lock		-- probably should stay "nolock" as I don't think
			   the device aliasing code handles lock-state
			   transfer, and it's probably better to do=20
			   nothing than rely on incorrect state.

sync_lock		-- not sure about this one. Do we still use it
			   given our new fss implementation?

mfs_lock		-- AFAICT used for the node that is the "device"
			   node for an mfs mount. Probably can be changed
			   to genfs_lock() w/o issue - I think only the
			   bio routines use this node, and they never
			   played with the vnode lock before. :-)

union_lock		-- has a call to genfs_nolock(). cvs blame=20
			   indicates we got it from the Lite 2 merge,
			   but I can't figure out what it's doing, other
			   than possibly unlocking the interlock.=20
			   Regardless, has no impact on layered file
			   systems on top of a unionfs.

With the shadow locking gone, there will be no need to look at v_lock's=20
state.

Take care,

Bill

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

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

iD8DBQFA1NgeWz+3JHUci9cRAi1zAJ9dGjQz9nts5dxIIRG+T1A/x4SVywCeOOuc
ndqLpXs9JHX7qgK+JQ4zwjE=
=hp/d
-----END PGP SIGNATURE-----

--HeFlAV5LIbMFYYuh--