Re: valid dup lock logic for witness

• Previous message: John Baldwin: "Re: adv(4) bandaid [Was Re: again question about "IRQ 2 problem"]"
• In reply to: John-Mark Gurney: "Re: valid dup lock logic for witness"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

To: freebsd-arch@FreeBSD.org, John-Mark Gurney <gurney_j@resnet.uoregon.edu>
Date: Thu, 12 Aug 2004 09:23:42 -0400

On Thursday 12 August 2004 01:57 am, John-Mark Gurney wrote:
> John Baldwin wrote this message on Mon, Aug 09, 2004 at 10:26 -0400:
> > 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.
>
> How about that, but making the dup lock ok w/ a signle parent lock a
> generic function. I would imagine there are a finite number of ways
> to solve duplicate locks, and they will end up being shared between
> different subsystems.

Making it a generic function will be slower. You can have the kqueue dup
check function look something like:

int
kqueue_check_dup(struct lock_object *l1, struct lock_object *l2)
{
        return (mtx_owned(&kqueue_master_dup_lock));
}

(Where the dup function returns 1 if the dup is ok and 0 if it is not).

-- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/
_______________________________________________
freebsd-arch@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

• Previous message: John Baldwin: "Re: adv(4) bandaid [Was Re: again question about "IRQ 2 problem"]"
• In reply to: John-Mark Gurney: "Re: valid dup lock logic for witness"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]