--=-=-=


Greg Troxel <gdt@ir.bbn.com> writes:

>   > It seems that this will fail if someone else has the vnode locked, and
>   > there will be no retry.  From reading vn_lock, it seems that if one
>   > passes LK_NOWAIT, that on encountering a locked vnode, vn_lock returns
>   > immediately.  If LK_NOWAIT is not set, and LK_RETRY is also not set,
>   > it seems that vn_lock will tsleep on the vnode's v_interlock, and then
>   > return ENOENT instead of retrying.  The ufs code uses LK_RETRY in what
>   > I think is the analogous case.
>   > 
>   > I don't understand why it makes sense to sleep and not retry the lock
>   > - if one isn't going to retry, what's the point of sleeping?
>   > 
>   > So, I think that coda_lookup should pass LK_RETRY.  But I either don't
>   > quite or just barely understand vnode locking, so I'd appreciate
>   > advice here.
>
>   Your analysis might be right. Does it work fine if you try
>   changing the source to use LK_EXCLUSIVE|LK_RETRY in
>   the vn_lock() call?
>
> I'll patch and see

should the lock on the child be claimed before the lock on parent is
dropped ?

Love


--=-=-=
Content-Type: application/pgp-signature

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

iQIVAwUAQTtYJhZyDLTSep3UAQJ0pw//Uc56Ecjmy4yLlgcXL1u1WkpT+JlQUh8U
h/RgkBuDRyu2LB/r3ZeDucR/zIXRdUxYfegiBuLfsEykyVZ57X7HinnBwDUpM0bW
Qz7qD3gBC2MthiCelkKdgW2xqIWnWTAWr9/4F9F8fHf+Vd3XRzku6zNlEfk9ie3V
KEzWTL3oPkHMSCyMzKNKDxwJFQTi3rZzOcS+Y7hn84iuHFqT0JnlPLqCTBjs+5cr
nWwhHZAX3e/L6fI2CNtdneBo6y6FIPSfAELhMcrS69pbUT6a9sDFaS4dvmjDI3QV
XVxNHvHFfUFJJMLgLUZlWLTexEOueFBBvx49x0yOadxEN8Y6vuegGkB37Jc6/Gpn
S9ISTrddo6Dr8OdEEzruY4jIKckuxX27A5uqQJKBVrr20X+b5zgMQ/9lXFqr2tCl
m6nLrHsD7xOy5DBso09cxZzYVf4OYXbkuowy4NbDD/pqIWt2k4BlNKc6LeEVvEeY
dZnnoeatIU1XNZtwdbd6B18AEG8Q5J/FoovI/CEHd25ceCLFsIwwfnY+GBBZl4G7
2zQ2AarLGMJPfCOVb6Za1A947czSpJUqOnajet2mvkTekKZKN+wQ0eqTTvIQ0+Rq
ijb6pGzEwPyoBrA/29JjA8v8VLWWRRX091k8yetduI2Mw0eQ9eKVoP/Eh5lMp5Vu
cZJ2xAlgT0E=
=9tgG
-----END PGP SIGNATURE-----
--=-=-=--