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>