Name: Add Al Viro's Recursive Lock Warning to Locking Guide
Status: Trivial

Jeff Garzik says:
> So, I was wondering, is there a place in your kernel locking guide for 
> some words for viro?  I felt it approached a good explanation, and 
> deserved recording in the kernel docs somewhere.

Although Al's quote is disappointingly innocuous, I've included it
below.  It stands well on its own, so I don't think it needs an
introduction.

diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .17786-linux-2.6.3-rc3-bk1/Documentation/DocBook/kernel-locking.tmpl .17786-linux-2.6.3-rc3-bk1.updated/Documentation/DocBook/kernel-locking.tmpl
--- .17786-linux-2.6.3-rc3-bk1/Documentation/DocBook/kernel-locking.tmpl	2004-02-17 11:09:54.000000000 +1100
+++ .17786-linux-2.6.3-rc3-bk1.updated/Documentation/DocBook/kernel-locking.tmpl	2004-02-17 11:32:15.000000000 +1100
@@ -243,6 +243,17 @@
      Neither type of lock is recursive: see
      <xref linkend="deadlock">.
    </para>
+   <blockquote><attribution>Al Viro</attribution>
+   <para>
+     Recursive locks at the very least require careful audit.
+     Preferable outcome of said audit would be a switch to normal
+     locking primitives - in all cases I've seen recursive locks were
+     a source of deadlocks.  They can be, in theory, used correctly.  In
+     practice they are _not_.  IOW, their use is a very serious
+     warning and proof of correctness is practically the same work as
+     eliminating them completely.
+   </para>
+   </blockquote>
    </sect1>
  
    <sect1 id="uniprocessor">