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

On Tue, Aug 30, 2005 at 06:50:36PM +0200, Julio M. Merino Vidal wrote:
> Hi all,
>=20
> While implementing tmpfs' vnode operations, I think I've found
> several inconsistencies between the vnodeops(9) manual page
> and existing code (as seen in ufs and msdosfs, for example)
> as regards locking status.  I'm going to put these inconsistencies
> here so that we can either fix the manual page, the code or my
> understanding on the whole issue.

The canonical reference is supposed to be sys/kern/vnode_if.src.

> - vnodeops(9) says that vop_getattr receives a locked vnode,
>   which must remain locked on exit.  However, the operation
>   receives a locked or unlocked vnode, depending on the
>   situation.

Man page is wrong. vnode_if.src indicates that the vnode lock state is "=3D=
"=20
which means output is the same as input, either locked or unlocked.

> - vnodeops(9) says that vop_link's dvp is locked on entry and
>   should remain locked on exit.  However, file-systems do an
>   vput(dvp) before exiting the function, thus unlocking it.

vnode_if.src indicates that dvp is locked on entry and unlocked and=20
released on exit.

> - vnodeops(9) says that vop_rmdir should return with dvp and
>   vp locked.  However, file-systems do an vput of both
>   vnodes; this means that dvp is unlocked upon return and that
>   vp is possibly invalid (if it has been immediately reclaimed),
>   so it cannot be locked.

vnode_if.src indicates that both dvp and vp are vput() on exit.

> Comments?

Man page is wrong. :-)

Take care,

Bill

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

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

iD8DBQFDFKcbWz+3JHUci9cRAhflAKCWoVA8weT55/fh6DEt1zd3ZvYWwACgiJZ+
aQi8RDxHNsZJcyJVEggcHAw=
=oKG7
-----END PGP SIGNATURE-----

--z0eOaCaDLjvTGF2l--