Date: Thu, 12 Aug 2004 09:23:42 -0400 From: John Baldwin <jhb@FreeBSD.org> To: freebsd-arch@FreeBSD.org, John-Mark Gurney <gurney_j@resnet.uoregon.edu> Subject: Re: valid dup lock logic for witness Message-ID: <200408120923.42973.jhb@FreeBSD.org> In-Reply-To: <20040812055712.GC991@funkthat.com> References: <20040806224316.GB991@funkthat.com> <200408091026.35755.jhb@FreeBSD.org> <20040812055712.GC991@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200408120923.42973.jhb>