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

On Fri, Apr 06, 2007 at 06:35:01PM -0400, Greg Troxel wrote:
> I'm trying to straighten out coda's vnodeops, and am confused by a
> discrepancy between the documenation and code about handling dvp args in
> a number of ops.
>=20
> vnodeops(9) says:
>=20
>      VOP_CREATE(dvp, vpp, cnp, vap)
>               Create a new file in a given directory.  The argument dvp i=
s the
>               locked vnode of the directory to create the new file in and=
 cnp
>               is the pathname component of the new file.  The argument vap
>               specifies the attributes that the new file should be created
>               with.  If the file is successfully created, the address of =
the
>               resulting locked vnode is returned in vpp and zero is retur=
ned.
>               Regardless of the return value, the directory vnode dvp wil=
l be
>               unlocked on return.

That should be unlocked and released.

> so I would think that the vnop implementation should do VOP_UNLOCK on
> dvp.  But the coda coda does vput, and puffs does too.
>=20
> I expected that the caller of VOP_CREATE would hold a ref, and that
> VOP_CREATE would ride that ref, so it seems odd to release it.
>=20
> What's the right behavior, and should vnodeops(9) be fixed?

Look in vnode_if.src. Unfortunately vnodeops(9) has been wrong since day=20
1. vnode_if.src has:

#         =20
#% create     dvp     L U U
#% create     vpp     - L -
#         =20
#! create cnp   CREATE, LOCKPARENT=20
#         =20
vop_create {
        IN LOCKED=3DYES WILLPUT struct vnode *dvp;
        OUT struct vnode **vpp;
        IN struct componentname *cnp;=20
        IN struct vattr *vap;
};


The "WILLPUT" is kinda new, but the "L" to "-" behavior =3D=3D unlock and=
=20
release has been that way since well before 4.4BSD.

It would be nice to not have ops auto-release references. I think freebsd=
=20
has cleaned things up here and we should look at that.

Take care,

Bill

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

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

iD8DBQFGFu0/Wz+3JHUci9cRAvTUAJ9S3v/EZPXSDOV/3zc1ArOeiVevywCdFkps
PIca9yyTCqg2IGrhEA0uR0w=
=aJJQ
-----END PGP SIGNATURE-----

--X1bOJ3K7DJ5YkBrT--