kern/116133: Recursive lock panic when w_mtx falls into DELAY

[Russell Cattelan]

>Number:         116133
>Category:       kern
>Synopsis:       Recursive lock panic when w_mtx falls into DELAY
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Sep 05 19:40:01 GMT 2007
>Closed-Date:
>Last-Modified:
>Originator:     Russell Cattelan
>Release:        FreeBSD 6.2-STABLE amd64
>Organization:
>Environment:
System: FreeBSD mist 6.2-STABLE FreeBSD 6.2-STABLE #0: Mon Mar 26 14:29:16 CDT 2007 cattelan at mist:/usrX/src6/sys/amd64/compile/MIST amd64


	
>Description:
	
Set the MTX_NOWITNESS flag on the clock_lock.
Since witness uses mtx_spin_lock internally, any delay
on getting the w_mtx lock would cause mtx_spin_lock to
fall into the "adaptive" mode and call DELAY internally.
DELAY grabs the clock_lock which is also will
try to grab the w_mtx mutex trying to insert the clock_lock
into the witness data structures. The end result is a
recurse lock panic.
>How-To-Repeat:
	
>Fix:

	
Index: tango-client/src/freebsd6/src/sys/amd64/amd64/machdep.c
===================================================================
--- tango-client.orig/src/freebsd6/src/sys/amd64/amd64/machdep.c  2007-09-04 16:17:53.318140386 -0500
+++ tango-client/src/freebsd6/src/sys/amd64/amd64/machdep.c 2007-09-05 13:29:55.980183838 -0500
@@ -1211,9 +1211,14 @@ hammer_time(u_int64_t modulep, u_int64_t
   *       section, to set pcpu->ipending (etc...) properly, we
   *       must be able to get the icu lock, so it can't be
   *       under witness.
+  * clock_lock: the adaptive nature of the mutex_spin lock could
+  *           cause obtaining the w_mtx lock to fall into DELAY
+  *       which would then cause a recursive lock panic when
+  *       grabbing the clock_lock and subsequently the w_mtx
+  *           as part of the mtx_lock_spin(clock_lock) call.
   */
  mutex_init();
- mtx_init(&clock_lock, "clk", NULL, MTX_SPIN);
+ mtx_init(&clock_lock, "clk", NULL, MTX_SPIN | MTX_NOWITNESS);
  mtx_init(&icu_lock, "icu", NULL, MTX_SPIN | MTX_NOWITNESS);

  /* exceptions */
Index: tango-client/src/freebsd6/src/sys/i386/i386/machdep.c
===================================================================
--- tango-client.orig/src/freebsd6/src/sys/i386/i386/machdep.c  2007-09-03 16:21:05.000000000 -0500
+++ tango-client/src/freebsd6/src/sys/i386/i386/machdep.c 2007-09-05 13:29:40.490965402 -0500
@@ -2135,9 +2135,14 @@ init386(first)
   *       section, to set pcpu->ipending (etc...) properly, we
   *       must be able to get the icu lock, so it can't be
   *       under witness.
+  * clock_lock: the adaptive nature of the mutex_spin lock could
+  *           cause obtaining the w_mtx lock to fall into DELAY
+  *       which would then cause a recursive lock panic when
+  *       grabbing the clock_lock and subsequently the w_mtx
+  *           as part of the mtx_lock_spin(clock_lock) call.
   */
  mutex_init();
- mtx_init(&clock_lock, "clk", NULL, MTX_SPIN);
+ mtx_init(&clock_lock, "clk", NULL, MTX_SPIN | MTX_NOWITNESS);
  mtx_init(&icu_lock, "icu", NULL, MTX_SPIN | MTX_NOWITNESS);

  /* make ldt memory segments */



>Release-Note:
>Audit-Trail:
>Unformatted: