On Wed, 24 Mar 1999, Bill Sommerfeld wrote:

> Allowing a recursive lock here is also wrong, as the fault is
> presumably occurring in the middle of a copyout() in the middle of the
> outer VOP_READ(), and the vnode may not be in a state that reentering
> VOP_READ could possibly work..
> 
> I think the right answer in the short term is to add a new flag bit to
> the lockmgr to indicate that locking against self is a non-fatal
> condition, and should just cause the lockmgr call to fail instead of a
> panic, and then pass that flag (and test for that error) in
> uvm_vnode.c. and return EDEADLK.
> 
> This should be simple to add and test.  Comments?

I like the idea, but I'd suggest we do it differently. I'd suggest we add
a new lock manager call, lock_haslock(), which takes a lock and a proc
(pointer), and indicates if that proc is the lock holder. Then we add
vn_haslock which takes a vnode and a proc and calls lock_islocked on the
lock.

That way code can test early on if it is the process which has the lock,
and can react accordingly (for instance realizing it can't sleep when it
otherwise might be able to).

Take care,

Bill