svn commit: r41038 - head/en_US.ISO8859-1/books/faq

Giorgos Keramidas keramida at FreeBSD.org
Sun Feb 24 22:19:55 UTC 2013


Author: keramida
Date: Sun Feb 24 22:19:53 2013
New Revision: 41038
URL: http://svnweb.freebsd.org/changeset/doc/41038

Log:
  Expand a bit the description of a LOR and what witness does
  
  While here try to explain a bit why a deadlock could happen when
  witness(4) reports a ’lock order reversal’ and why ’reversal’ is
  an important part of the deadlock-related warning.
  
  Approved by:    gjb (mentor)
  Reviewed by:   eadler

Modified:
  head/en_US.ISO8859-1/books/faq/book.xml

Modified: head/en_US.ISO8859-1/books/faq/book.xml
==============================================================================
--- head/en_US.ISO8859-1/books/faq/book.xml	Sun Feb 24 16:58:04 2013	(r41037)
+++ head/en_US.ISO8859-1/books/faq/book.xml	Sun Feb 24 22:19:53 2013	(r41038)
@@ -2494,18 +2494,37 @@ kern.timecounter.hardware: TSC -> i82
 
 	<answer>
 	  <para>The &os; kernel uses a number of resource locks to
-	    arbitrate contention for certain resources.  A run-time
-	    lock diagnostic system found in &os.current; kernels
-	    (but removed for releases), called &man.witness.4;,
-	    detects the potential for deadlocks due to locking errors.
-	    (It is possible to get false positives, as &man.witness.4;
-	    is slightly conservative.) A true positive report
-	    indicates that "if you were unlucky, a deadlock would have
-	    happened here">.</para>
-
-	  <para>Problematic <acronym>LOR</acronym>s tend to get fixed
-	    quickly, so check &a.current.url; before posting to the
-	    mailing lists.</para>
+	    arbitrate contention for certain resources.  When multiple
+	    kernel threads try to obtain multiple resource locks,
+	    there's always the potential for a deadlock,
+	    where two threads have each obtained one of the locks and
+	    blocks forever waiting for the other thread to release one
+	    of the other locks.  This sort of locking problem can be
+	    avoided if all threads obtain the locks in the same
+	    order.</para>
+
+	  <para>A run-time lock diagnostic system called &man.witness.4;,
+	    enabled in &os.current; and disabled by default for stable
+	    branches and releases, detects the potential for deadlocks due to
+	    locking errors, including errors caused by obtaining multiple
+	    resource locks with a different order from different parts of the
+	    kernel.  The &man.witness.4; framework tries to detect this
+	    problem as it happens, and reports it by printing a message to the
+	    system console about a <errorname>lock order reversal</errorname>
+	    (often referred to also as <acronym>LOR</acronym>).</para>
+
+	  <para>It is possible to get false positives, as &man.witness.4;
+	    is conservative.  A true positive report <emphasis>does
+	      not</emphasis> mean that a system is dead-locked; instead
+	    it should be understood as a warning of the form <quote>if
+	      you were unlucky, a deadlock would have happened
+	      here</quote>.</para>
+
+	  <note>
+	    <para>Problematic <acronym>LOR</acronym>s tend to get fixed
+	      quickly, so check &a.current.url; before posting to the
+	      mailing lists.</para>
+	  </note>
 	</answer>
       </qandaentry>
 


More information about the svn-doc-all mailing list