valid dup lock logic for witness

[John Baldwin]

On Friday 06 August 2004 06:43 pm, John-Mark Gurney wrote:
> I have been working on kqueue, and to support kq in kq, I need to obtain
> two kq locks (both of the same type) at the same time.  Normally this can
> cause a deadlock, but using a proper lock ordering strategy, it can be
> avoided.  In the kq case, I chose to aquire a kq global lock before
> acquiring multiple kq locks.  (In the proc case, jhb said you aquire
> the child's before the parents.)
>
> Mutexs have the flag MTX_DUPOK that notify witness that duplicate locks
> are ok, but this can hide other problems (and in fact would have in my
> testing).
>
> I have created a patch that lets you inform witness the a duplicate lock
> is valid as long as you hold another lock.  The only run time change is
> that when a duplicate lock is found, it will run through another table
> to verify it's ok before printing out the back trace.
>
> Anyone have objections to this?

As I said on IRC, my objection to this is that there are numerous ways of 
acquiring duplicate locks in a valid fashion.  For kq there is a global lock 
around such cases.  For proc locks child processes are locked before parents. 
The problem is that there is not a single way of doing this, so if you want 
WITNESS to check all of these, you will have to add lots of special case 
one-off hacks to WITNESS making it even more obtuse and slow.  Perhaps 
something that might be feasible is to provide some sort of way for other 
parts of the kernel to register a duplicate check function for a given lock 
type.  This would let you keep the code doing the duplicate check closer to 
the code using the locks for one thing and would avoid adding N hacks to 
witness for the various different dup lock checks.

-- 
John Baldwin <jhb at FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org