os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Expand a bit the description of a LOR and what witness does

Browse source 
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
This commit is contained in:
Giorgos Keramidas 2013-02-24 22:19:53 +00:00
parent c77b86c7a2
commit b02e847a22
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=41038
1 changed files with 30 additions and 11 deletions

41
en_US.ISO8859-1/books/faq/book.xml
View file

@ -2494,18 +2494,37 @@ kern.timecounter.hardware: TSC -&gt; i8254</screen>
<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>
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>Problematic <acronym>LOR</acronym>s tend to get fixed
quickly, so check &a.current.url; before posting to the
mailing lists.</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>