Re: valid dup lock logic for witness
From: John-Mark Gurney (gurney_j_at_resnet.uoregon.edu)
Date: 08/12/04
- Previous message: Julian Elischer: "[Fwd: [Fwd: RFC.. defining __rangeof() in cdefs.h]]"
- In reply to: John Baldwin: "Re: valid dup lock logic for witness"
- Next in thread: John Baldwin: "Re: valid dup lock logic for witness"
- Reply: John Baldwin: "Re: valid dup lock logic for witness"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 11 Aug 2004 22:57:12 -0700 To: John Baldwin <jhb@FreeBSD.org>
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.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
_______________________________________________
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: Julian Elischer: "[Fwd: [Fwd: RFC.. defining __rangeof() in cdefs.h]]"
- In reply to: John Baldwin: "Re: valid dup lock logic for witness"
- Next in thread: John Baldwin: "Re: valid dup lock logic for witness"
- Reply: John Baldwin: "Re: valid dup lock logic for witness"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
