Re: Tracking down LORs

From: Robert Watson <rwatson_at_freebsd.org>
Date: Fri, 20 Aug 2004 00:12:05 -0400 (EDT)
On Fri, 20 Aug 2004, Roman Kurakin wrote:

> 	Currently I am trying to track down a couple of LORS in my code.
> But it seems that I do not undestand smth or all things id realy so bad. 

I find it's very helpful to add lock orders to the hard-coded lock order
table in subr_witness.c.  Without hard-coded entries, WITNESS will
dynamically build an order based on observed lock use.  This is generally
fine, but once in a while the "wrong" order will be used before the
"right" order, so the lock order warning will print for the "right" order,
leaving less useful debugging information.  The table allows the
definition of partial orders, so you can specify relationships between
subsets of mutexes of interest.  WITNESS will flesh out remaining orders
through dynamic discovery.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Principal Research Scientist, McAfee Research


> 
> 	So I want to ask some questions to find out if my thoughts
> correct or wrong.
> 
> 1. If I am right LOR means that we have at least two mutexs.
> Lets call them a and b. If we set a, then b in first case
> and b then a in second we could get dead loop, and thus LOR.
> 
> 2. If I have some driver that have mutex a, and we have some
> sytem code that could call this driver with Giant (b), we would
> get LOR if driver lock a and some other part of system will
> try to lock Giant?
> 
> or I am wrong?
> 
> rik
> 
> 
> 
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> 
Received on Fri Aug 20 2004 - 02:14:11 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:07 UTC