Patched in Tegra support.

13 files changed, 417 insertions, 2459 deletions

diff --git a/Documentation/RCU/NMI-RCU.txt b/Documentation/RCU/NMI-RCU.txt
index 687777f83b2..bf82851a0e5 100644
--- a/Documentation/RCU/NMI-RCU.txt
+++ b/Documentation/RCU/NMI-RCU.txt
@@ -95,7 +95,7 @@ not to return until all ongoing NMI handlers exit.  It is therefore safe
 to free up the handler's data as soon as synchronize_sched() returns.
 
 Important note: for this to work, the architecture in question must
-invoke nmi_enter() and nmi_exit() on NMI entry and exit, respectively.
+invoke irq_enter() and irq_exit() on NMI entry and exit, respectively.
 
 
 Answer to Quick Quiz
diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt
index 7f40c72a9c5..c43460dade0 100644
--- a/Documentation/RCU/RTFP.txt
+++ b/Documentation/RCU/RTFP.txt
@@ -1,10 +1,9 @@
-Read the Fscking Papers!
+Read the F-ing Papers!
 
 
 This document describes RCU-related publications, and is followed by
 the corresponding bibtex entries.  A number of the publications may
-be found at http://www.rdrop.com/users/paulmck/RCU/.  For others, browsers
-and search engines will usually find what you are looking for.
+be found at http://www.rdrop.com/users/paulmck/RCU/.
 
 The first thing resembling RCU was published in 1980, when Kung and Lehman
 [Kung80] recommended use of a garbage collector to defer destruction
@@ -161,46 +160,19 @@ which Mathieu Desnoyers is now maintaining [MathieuDesnoyers2009URCU]
 [MathieuDesnoyersPhD].  TINY_RCU [PaulEMcKenney2009BloatWatchRCU] made
 its appearance, as did expedited RCU [PaulEMcKenney2009expeditedRCU].
 The problem of resizeable RCU-protected hash tables may now be on a path
-to a solution [JoshTriplett2009RPHash].  A few academic researchers are now
-using RCU to solve their parallel problems [HariKannan2009DynamicAnalysisRCU].
-
-2010 produced a simpler preemptible-RCU implementation
-based on TREE_RCU [PaulEMcKenney2010SimpleOptRCU], lockdep-RCU
-[PaulEMcKenney2010LockdepRCU], another resizeable RCU-protected hash
-table [HerbertXu2010RCUResizeHash] (this one consuming more memory,
-but allowing arbitrary changes in hash function, as required for DoS
-avoidance in the networking code), realization of the 2009 RCU-protected
-hash table with atomic node move [JoshTriplett2010RPHash], an update on
-the RCU API [PaulEMcKenney2010RCUAPI].
-
-2011 marked the inclusion of Nick Piggin's fully lockless dentry search
-[LinusTorvalds2011Linux2:6:38:rc1:NPigginVFS], an RCU-protected red-black
-tree using software transactional memory to protect concurrent updates
-(strange, but true!) [PhilHoward2011RCUTMRBTree], yet another variant of
-RCU-protected resizeable hash tables [Triplett:2011:RPHash], the 3.0 RCU
-trainwreck [PaulEMcKenney2011RCU3.0trainwreck], and Neil Brown's "Meet the
-Lockers" LWN article [NeilBrown2011MeetTheLockers].
-
+to a solution [JoshTriplett2009RPHash].
 
 Bibtex Entries
 
 @article{Kung80
 ,author="H. T. Kung and Q. Lehman"
-,title="Concurrent Manipulation of Binary Search Trees"
+,title="Concurrent Maintenance of Binary Search Trees"
 ,Year="1980"
 ,Month="September"
 ,journal="ACM Transactions on Database Systems"
 ,volume="5"
 ,number="3"
 ,pages="354-382"
-,note="Available:
-\url{http://portal.acm.org/citation.cfm?id=320619&dl=GUIDE,}
-[Viewed December 3, 2007]"
-,annotation={
-        Use garbage collector to clean up data after everyone is done with it.
-        .
-        Oldest use of something vaguely resembling RCU that I have found.
-}
 }
 
 @techreport{Manber82
@@ -212,31 +184,6 @@ Bibtex Entries
 ,number="82-01-01"
 ,month="January"
 ,pages="28"
-,annotation={
-        .
-        Superseded by Manber84.
-        .
-        Describes concurrent AVL tree implementation.  Uses a
-        garbage-collection mechanism to handle concurrent use and deletion
-        of nodes in the tree, but lacks the summary-of-execution-history
-        concept of read-copy locking.
-        .
-        Keeps full list of processes that were active when a given
-        node was to be deleted, and waits until all such processes have
-        -terminated- before allowing this node to be reused.  This is
-        not described in great detail -- one could imagine using process
-        IDs for this if the ID space was large enough that overlapping
-        never occurred.
-        .
-        This restriction makes this algorithm unsuitable for use in
-        systems comprised of long-lived processes.  It also produces
-        completely unacceptable overhead in systems with large numbers
-        of processes.  Finally, it is specific to AVL trees.
-        .
-        Cites Kung80, so not an independent invention, but the first
-        RCU-like usage that does not rely on an automatic garbage
-        collector.
-}
 }
 
 @article{Manber84
@@ -248,74 +195,6 @@ Bibtex Entries
 ,volume="9"
 ,number="3"
 ,pages="439-455"
-,annotation={
-        Describes concurrent AVL tree implementation.  Uses a
-        garbage-collection mechanism to handle concurrent use and deletion
-        of nodes in the tree, but lacks the summary-of-execution-history
-        concept of read-copy locking.
-        .
-        Keeps full list of processes that were active when a given
-        node was to be deleted, and waits until all such processes have
-        -terminated- before allowing this node to be reused.  This is
-        not described in great detail -- one could imagine using process
-        IDs for this if the ID space was large enough that overlapping
-        never occurred.
-        .
-        This restriction makes this algorithm unsuitable for use in
-        systems comprised of long-lived processes.  It also produces
-        completely unacceptable overhead in systems with large numbers
-        of processes.  Finally, it is specific to AVL trees.
-}
-}
-
-@Conference{RichardRashid87a
-,Author="Richard Rashid and Avadis Tevanian and Michael Young and
-David Golub and Robert Baron and David Black and William Bolosky and
-Jonathan Chew"
-,Title="Machine-Independent Virtual Memory Management for Paged
-Uniprocessor and Multiprocessor Architectures"
-,Booktitle="{2\textsuperscript{nd} Symposium on Architectural Support
-for Programming Languages and Operating Systems}"
-,Publisher="Association for Computing Machinery"
-,Month="October"
-,Year="1987"
-,pages="31-39"
-,Address="Palo Alto, CA"
-,note="Available:
-\url{http://www.cse.ucsc.edu/~randal/221/rashid-machvm.pdf}
-[Viewed February 17, 2005]"
-,annotation={
-        Describes lazy TLB flush, where one waits for each CPU to pass
-        through a scheduling-clock interrupt before reusing a given range
-        of virtual address.  Does not describe how one determines that
-        all CPUs have in fact taken such an interrupt, though there are
-        no shortage of straightforward methods for accomplishing this.
-        .
-        Note that it does not make sense to just wait a fixed amount of
-        time, since a given CPU might have interrupts disabled for an
-        extended amount of time.
-}
-}
-
-@article{BarbaraLiskov1988ArgusCACM
-,author = {Barbara Liskov}
-,title = {Distributed programming in {Argus}}
-,journal = {Commun. ACM}
-,volume = {31}
-,number = {3}
-,year = {1988}
-,issn = {0001-0782}
-,pages = {300--312}
-,doi = {http://doi.acm.org/10.1145/42392.42399}
-,publisher = {ACM}
-,address = {New York, NY, USA}
-,annotation= {
-        At the top of page 307: "Conflicts with deposits and withdrawals
-        are necessary if the reported total is to be up to date.  They
-        could be avoided by having total return a sum that is slightly
-        out of date."  Relies on semantics -- approximate numerical
-        values sometimes OK.
-}
 }
 
 @techreport{Hennessy89
@@ -337,13 +216,6 @@ for Programming Languages and Operating Systems}"
 ,year="1990"
 ,number="CS-TR-2222.1"
 ,month="June"
-,annotation={
-        Concurrent access to skip lists.  Has both weak and strong search.
-        Uses concept of ``garbage queue'', but has no real way of cleaning
-        the garbage efficiently.
-        .
-        Appears to be an independent invention of an RCU-like mechanism.
-}
 }
 
 @Book{Adams91
@@ -351,15 +223,20 @@ for Programming Languages and Operating Systems}"
 ,title="Concurrent Programming, Principles, and Practices"
 ,Publisher="Benjamin Cummins"
 ,Year="1991"
-,annotation={
-        Has a few paragraphs describing ``chaotic relaxation'', a
-        numerical analysis technique that allows multiprocessors to
-        avoid synchronization overhead by using possibly-stale data.
-        .
-        Seems like this is descended from yet another independent
-        invention of RCU-like function -- but this is restricted
-        in that reclamation is not necessary.
 }
+
+@phdthesis{HMassalinPhD
+,author="H. Massalin"
+,title="Synthesis: An Efficient Implementation of Fundamental Operating
+System Services"
+,school="Columbia University"
+,address="New York, NY"
+,year="1992"
+,annotation="
+        Mondo optimizing compiler.
+        Wait-free stuff.
+        Good advice: defer work to avoid synchronization.
+"
 }
 
 @unpublished{Jacobson93
@@ -367,13 +244,7 @@ for Programming Languages and Operating Systems}"
 ,title="Avoid Read-Side Locking Via Delayed Free"
 ,year="1993"
 ,month="September"
-,note="private communication"
-,annotation={
-        Use fixed time delay to approximate grace period.  Very simple,
-        but subject to random memory corruption under heavy load.
-        .
-        Independent invention of RCU-like mechanism.
-}
+,note="Verbal discussion"
 }
 
 @Conference{AjuJohn95
@@ -385,17 +256,6 @@ for Programming Languages and Operating Systems}"
 ,Year="1995"
 ,pages="11-23"
 ,Address="New Orleans, LA"
-,note="Available:
-\url{https://www.usenix.org/publications/library/proceedings/neworl/full_papers/john.a}
-[Viewed October 1, 2010]"
-,annotation={
-        Age vnodes out of the cache, and have a fixed time set by a kernel
-        parameter.  Not clear that all races were in fact correctly handled.
-        Used a 20-minute time by default, which would most definitely not
-        be suitable during DoS attacks or virus scans.
-        .
-        Apparently independent invention of RCU-like mechanism.
-}
 }
 
 @conference{Pu95a,
@@ -441,47 +301,31 @@ Utilizing Execution History and Thread Monitoring"
 ,institution="US Patent and Trademark Office"
 ,address="Washington, DC"
 ,year="1995"
-,number="US Patent 5,442,758"
+,number="US Patent 5,442,758 (contributed under GPL)"
 ,month="August"
-,annotation={
-        Describes the parallel RCU infrastructure.  Includes NUMA aspect
-        (structure of bitmap can reflect bus structure of computer system).
-        .
-        Another independent invention of an RCU-like mechanism, but the
-        "real" RCU this time!
-}
 }
 
 @techreport{Slingwine97
 ,author="John D. Slingwine and Paul E. McKenney"
-,title="Method for Maintaining Data Coherency Using Thread Activity
-Summaries in a Multicomputer System"
+,title="Method for maintaining data coherency using thread
+activity summaries in a multicomputer system"
 ,institution="US Patent and Trademark Office"
 ,address="Washington, DC"
 ,year="1997"
-,number="US Patent 5,608,893"
+,number="US Patent 5,608,893 (contributed under GPL)"
 ,month="March"
-,pages="19"
-,annotation={
-        Describes use of RCU to synchronize data between a pair of
-        SMP/NUMA computer systems.
-}
 }
 
 @techreport{Slingwine98
 ,author="John D. Slingwine and Paul E. McKenney"
-,title="Apparatus and Method for Achieving Reduced Overhead Mutual
-Exclusion and Maintaining Coherency in a Multiprocessor System
-Utilizing Execution History and Thread Monitoring"
+,title="Apparatus and method for achieving reduced overhead
+mutual exclusion and maintaining coherency in a multiprocessor
+system utilizing execution history and thread monitoring"
 ,institution="US Patent and Trademark Office"
 ,address="Washington, DC"
 ,year="1998"
-,number="US Patent 5,727,209"
+,number="US Patent 5,727,209 (contributed under GPL)"
 ,month="March"
-,annotation={
-        Describes doing an atomic update by copying the data item and
-        then substituting it into the data structure.
-}
 }
 
 @Conference{McKenney98
@@ -493,15 +337,6 @@ Problems"
 ,Year="1998"
 ,pages="509-518"
 ,Address="Las Vegas, NV"
-,note="Available:
-\url{http://www.rdrop.com/users/paulmck/RCU/rclockpdcsproof.pdf}
-[Viewed December 3, 2007]"
-,annotation={
-        Describes and analyzes RCU mechanism in DYNIX/ptx.  Describes
-        application to linked list update and log-buffer flushing.
-        Defines 'quiescent state'.  Includes both measured and analytic
-        evaluation.
-}
 }
 
 @Conference{Gamsa99
@@ -514,76 +349,18 @@ Operating System Design and Implementation}"
 ,Year="1999"
 ,pages="87-100"
 ,Address="New Orleans, LA"
-,note="Available:
-\url{http://www.usenix.org/events/osdi99/full_papers/gamsa/gamsa.pdf}
-[Viewed August 30, 2006]"
-,annotation={
-        Use of RCU-like facility in K42/Tornado.  Another independent
-        invention of RCU.
-        See especially pages 7-9 (Section 5).
-}
-}
-
-@unpublished{RustyRussell2000a
-,Author="Rusty Russell"
-,Title="Re: modular net drivers"
-,month="June"
-,year="2000"
-,day="23"
-,note="Available:
-\url{http://oss.sgi.com/projects/netdev/archive/2000-06/msg00250.html}
-[Viewed April 10, 2006]"
-,annotation={
-        Proto-RCU proposal from Phil Rumpf and Rusty Russell.
-        Yet another independent invention of RCU.
-        Outline of algorithm to unload modules...
-        .
-        Appeared on net-dev mailing list.
-}
-}
-
-@unpublished{RustyRussell2000b
-,Author="Rusty Russell"
-,Title="Re: modular net drivers"
-,month="June"
-,year="2000"
-,day="24"
-,note="Available:
-\url{http://oss.sgi.com/projects/netdev/archive/2000-06/msg00254.html}
-[Viewed April 10, 2006]"
-,annotation={
-        Proto-RCU proposal from Phil Rumpf and Rusty Russell.
-        .
-        Appeared on net-dev mailing list.
-}
-}
-
-@unpublished{McKenney01b
-,Author="Paul E. McKenney and Dipankar Sarma"
-,Title="Read-Copy Update Mutual Exclusion in {Linux}"
-,month="February"
-,year="2001"
-,note="Available:
-\url{http://lse.sourceforge.net/locking/rcu/rcupdate_doc.html}
-[Viewed October 18, 2004]"
-,annotation={
-        Prototypical Linux documentation for RCU.
-}
 }
 
 @techreport{Slingwine01
 ,author="John D. Slingwine and Paul E. McKenney"
-,title="Apparatus and Method for Achieving Reduced Overhead Mutual
-Exclusion and Maintaining Coherency in a Multiprocessor System
-Utilizing Execution History and Thread Monitoring"
+,title="Apparatus and method for achieving reduced overhead
+mutual exclusion and maintaining coherency in a multiprocessor
+system utilizing execution history and thread monitoring"
 ,institution="US Patent and Trademark Office"
 ,address="Washington, DC"
 ,year="2001"
-,number="US Patent 6,219,690"
+,number="US Patent 5,219,690 (contributed under GPL)"
 ,month="April"
-,annotation={
-        'Change in mode' aspect of RCU.  Can be thought of as a lazy barrier.
-}
 }
 
 @Conference{McKenney01a
@@ -595,61 +372,14 @@ Orran Krieger and Rusty Russell and Dipankar Sarma and Maneesh Soni"
 ,Year="2001"
 ,note="Available:
 \url{http://www.linuxsymposium.org/2001/abstracts/readcopy.php}
-\url{http://www.rdrop.com/users/paulmck/RCU/rclock_OLS.2001.05.01c.pdf}
+\url{http://www.rdrop.com/users/paulmck/rclock/rclock_OLS.2001.05.01c.pdf}
 [Viewed June 23, 2004]"
-,annotation={
-        Described RCU, and presented some patches implementing and using
-        it in the Linux kernel.
-}
-}
-
-@unpublished{McKenney01f
-,Author="Paul E. McKenney"
-,Title="{RFC:} patch to allow lock-free traversal of lists with insertion"
-,month="October"
-,year="2001"
-,note="Available:
-\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=100259266316456&w=2}
-[Viewed June 23, 2004]"
-,annotation="
-        Memory-barrier and Alpha thread.  100 messages, not too bad...
-"
-}
-
-@unpublished{Spraul01
-,Author="Manfred Spraul"
-,Title="Re: {RFC:} patch to allow lock-free traversal of lists with insertion"
-,month="October"
-,year="2001"
-,note="Available:
-\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=100264675012867&w=2}
-[Viewed June 23, 2004]"
-,annotation="
-        Suggested burying memory barriers in Linux's list-manipulation
-        primitives.
+annotation="
+Described RCU, and presented some patches implementing and using it in
+the Linux kernel.
 "
 }
 
-@unpublished{LinusTorvalds2001a
-,Author="Linus Torvalds"
-,Title="{Re:} {[Lse-tech]} {Re:} {RFC:} patch to allow lock-free traversal of lists with insertion"
-,month="October"
-,year="2001"
-,note="Available:
-\url{http://lkml.org/lkml/2001/10/13/105}
-[Viewed August 21, 2004]"
-}
-
-@unpublished{Blanchard02a
-,Author="Anton Blanchard"
-,Title="some RCU dcache and ratcache results"
-,month="March"
-,year="2002"
-,note="Available:
-\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=101637107412972&w=2}
-[Viewed October 18, 2004]"
-}
-
 @Conference{Linder02a
 ,Author="Hanna Linder and Dipankar Sarma and Maneesh Soni"
 ,Title="Scalability of the Directory Entry Cache"
@@ -657,10 +387,6 @@ Orran Krieger and Rusty Russell and Dipankar Sarma and Maneesh Soni"
 ,Month="June"
 ,Year="2002"
 ,pages="289-300"
-,annotation="
-        Measured scalability of Linux 2.4 kernel's directory-entry cache
-        (dcache), and measured some scalability enhancements.
-"
 }
 
 @Conference{McKenney02a
@@ -674,76 +400,49 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell"
 ,note="Available:
 \url{http://www.linux.org.uk/~ajh/ols2002_proceedings.pdf.gz}
 [Viewed June 23, 2004]"
-,annotation="
-        Presented and compared a number of RCU implementations for the
-        Linux kernel.
-"
 }
 
-@unpublished{Sarma02a
-,Author="Dipankar Sarma"
-,Title="specweb99: dcache scalability results"
-,month="July"
-,year="2002"
-,note="Available:
-\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=102645767914212&w=2}
-[Viewed June 23, 2004]"
+@conference{Michael02a
+,author="Maged M. Michael"
+,title="Safe Memory Reclamation for Dynamic Lock-Free Objects Using Atomic
+Reads and Writes"
+,Year="2002"
+,Month="August"
+,booktitle="{Proceedings of the 21\textsuperscript{st} Annual ACM
+Symposium on Principles of Distributed Computing}"
+,pages="21-30"
 ,annotation="
-        Compare fastwalk and RCU for dcache.  RCU won.
+        Each thread keeps an array of pointers to items that it is
+        currently referencing.  Sort of an inside-out garbage collection
+        mechanism, but one that requires the accessing code to explicitly
+        state its needs.  Also requires read-side memory barriers on
+        most architectures.
 "
 }
 
-@unpublished{Barbieri02
-,Author="Luca Barbieri"
-,Title="Re: {[PATCH]} Initial support for struct {vfs\_cred}"
-,month="August"
-,year="2002"
-,note="Available:
-\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=103082050621241&w=2}
-[Viewed: June 23, 2004]"
+@conference{Michael02b
+,author="Maged M. Michael"
+,title="High Performance Dynamic Lock-Free Hash Tables and List-Based Sets"
+,Year="2002"
+,Month="August"
+,booktitle="{Proceedings of the 14\textsuperscript{th} Annual ACM
+Symposium on Parallel
+Algorithms and Architecture}"
+,pages="73-82"
 ,annotation="
-        Suggested RCU for vfs\_shared\_cred.
+        Like the title says...
 "
 }
 
-@unpublished{Dickins02a
-,author="Hugh Dickins"
-,title="Use RCU for System-V IPC"
-,year="2002"
-,month="October"
-,note="private communication"
-}
-
-@unpublished{Sarma02b
-,Author="Dipankar Sarma"
-,Title="Some dcache\_rcu benchmark numbers"
+@InProceedings{HerlihyLM02
+,author={Maurice Herlihy and Victor Luchangco and Mark Moir}
+,title="The Repeat Offender Problem: A Mechanism for Supporting Dynamic-Sized,
+Lock-Free Data Structures"
+,booktitle={Proceedings of 16\textsuperscript{th} International
+Symposium on Distributed Computing}
+,year=2002
 ,month="October"
-,year="2002"
-,note="Available:
-\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=103462075416638&w=2}
-[Viewed June 23, 2004]"
-,annotation="
-        Performance of dcache RCU on kernbench for 16x NUMA-Q and 1x,
-        2x, and 4x systems.  RCU does no harm, and helps on 16x.
-"
-}
-
-@unpublished{LinusTorvalds2003a
-,Author="Linus Torvalds"
-,Title="Re: {[PATCH]} small fixes in brlock.h"
-,month="March"
-,year="2003"
-,note="Available:
-\url{http://lkml.org/lkml/2003/3/9/205}
-[Viewed March 13, 2006]"
-,annotation="
-        Linus suggests replacing brlock with RCU and/or seqlocks:
-        .
-        'It's entirely possible that the current user could be replaced
-        by RCU and/or seqlocks, and we could get rid of brlocks entirely.'
-        .
-        Steve Hemminger responds by replacing them with RCU.
-"
+,pages="339-353"
 }
 
 @article{Appavoo03a
@@ -758,20 +457,6 @@ B. Rosenburg and M. Stumm and J. Xenidis"
 ,volume="42"
 ,number="1"
 ,pages="60-76"
-,annotation="
-        Use of RCU to enable hot-swapping for autonomic behavior in K42.
-"
-}
-
-@unpublished{Seigh03
-,author="Joseph W. {Seigh II}"
-,title="Read Copy Update"
-,Year="2003"
-,Month="March"
-,note="email correspondence"
-,annotation="
-        Described the relationship of the VM/XA passive serialization to RCU.
-"
 }
 
 @Conference{Arcangeli03
@@ -785,27 +470,6 @@ Dipankar Sarma"
 ,year="2003"
 ,month="June"
 ,pages="297-310"
-,note="Available:
-\url{http://www.rdrop.com/users/paulmck/RCU/rcu.FREENIX.2003.06.14.pdf}
-[Viewed November 21, 2007]"
-,annotation="
-        Compared updated RCU implementations for the Linux kernel, and
-        described System V IPC use of RCU, including order-of-magnitude
-        performance improvements.
-"
-}
-
-@Conference{Soules03a
-,Author="Craig A. N. Soules and Jonathan Appavoo and Kevin Hui and
-Dilma {Da Silva} and Gregory R. Ganger and Orran Krieger and
-Michael Stumm and Robert W. Wisniewski and Marc Auslander and
-Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis"
-,Title="System Support for Online Reconfiguration"
-,Booktitle="Proceedings of the 2003 USENIX Annual Technical Conference"
-,Publisher="USENIX Association"
-,year="2003"
-,month="June"
-,pages="141-154"
 }
 
 @article{McKenney03a
@@ -817,22 +481,6 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis"
 ,volume="1"
 ,number="114"
 ,pages="18-26"
-,note="Available:
-\url{http://www.linuxjournal.com/article/6993}
-[Viewed November 14, 2007]"
-,annotation="
-        Reader-friendly intro to RCU, with the infamous old-man-and-brat
-        cartoon.
-"
-}
-
-@unpublished{Sarma03a
-,Author="Dipankar Sarma"
-,Title="RCU low latency patches"
-,month="December"
-,year="2003"
-,note="Message ID: 20031222180114.GA2248@in.ibm.com"
-,annotation="dipankar/ct.2004.03.27/RCUll.2003.12.22.patch"
 }
 
 @techreport{Friedberg03a
@@ -841,14 +489,9 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis"
 ,institution="US Patent and Trademark Office"
 ,address="Washington, DC"
 ,year="2003"
-,number="US Patent 6,662,184"
+,number="US Patent 6,662,184 (contributed under GPL)"
 ,month="December"
 ,pages="112"
-,annotation="
-        Applies RCU to a wildcard-search Patricia tree in order to permit
-        synchronization-free lookup.  RCU is used to retain removed nodes
-        for a grace period before freeing them.
-"
 }
 
 @article{McKenney04a
@@ -860,12 +503,6 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis"
 ,volume="1"
 ,number="118"
 ,pages="38-46"
-,note="Available:
-\url{http://www.linuxjournal.com/node/7124}
-[Viewed December 26, 2010]"
-,annotation="
-        Reader friendly intro to dcache and RCU.
-"
 }
 
 @Conference{McKenney04b
@@ -877,83 +514,8 @@ Michal Ostrowski and Bryan Rosenburg and Jimi Xenidis"
 ,Address="Adelaide, Australia"
 ,note="Available:
 \url{http://www.linux.org.au/conf/2004/abstracts.html#90}
-\url{http://www.rdrop.com/users/paulmck/RCU/lockperf.2004.01.17a.pdf}
+\url{http://www.rdrop.com/users/paulmck/rclock/lockperf.2004.01.17a.pdf}
 [Viewed June 23, 2004]"
-,annotation="
-        Compares performance of RCU to that of other locking primitives
-        over a number of CPUs (x86, Opteron, Itanium, and PPC).
-"
-}
-
-@unpublished{Sarma04a
-,Author="Dipankar Sarma"
-,Title="{[PATCH]} {RCU} for low latency (experimental)"
-,month="March"
-,year="2004"
-,note="\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=108003746402892&w=2}"
-,annotation="Head of thread: dipankar/2004.03.23/rcu-low-lat.1.patch"
-}
-
-@unpublished{Sarma04b
-,Author="Dipankar Sarma"
-,Title="Re: {[PATCH]} {RCU} for low latency (experimental)"
-,month="March"
-,year="2004"
-,note="\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=108016474829546&w=2}"
-,annotation="dipankar/rcuth.2004.03.24/rcu-throttle.patch"
-}
-
-@unpublished{Spraul04a
-,Author="Manfred Spraul"
-,Title="[RFC] 0/5 rcu lock update"
-,month="May"
-,year="2004"
-,note="Available:
-\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=108546407726602&w=2}
-[Viewed June 23, 2004]"
-,annotation="
-        Hierarchical-bitmap patch for RCU infrastructure.
-"
-}
-
-@unpublished{Steiner04a
-,Author="Jack Steiner"
-,Title="Re: [Lse-tech] [RFC, PATCH] 1/5 rcu lock update:
-Add per-cpu batch counter"
-,month="May"
-,year="2004"
-,note="Available:
-\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=108551764515332&w=2}
-[Viewed June 23, 2004]"
-,annotation={
-        RCU runs reasonably on a 512-CPU SGI using Manfred Spraul's patches,
-        which may be found at:
-        https://lkml.org/lkml/2004/5/20/49 (split vars into cachelines)
-        https://lkml.org/lkml/2004/5/22/114 (cpu_quiet() patch)
-        https://lkml.org/lkml/2004/5/25/24 (0/5)
-        https://lkml.org/lkml/2004/5/25/23 (1/5)
-                https://lkml.org/lkml/2004/5/25/265 (works for Jack)
-        https://lkml.org/lkml/2004/5/25/20 (2/5)
-        https://lkml.org/lkml/2004/5/25/22 (3/5)
-        https://lkml.org/lkml/2004/5/25/19 (4/5)
-        https://lkml.org/lkml/2004/5/25/21 (5/5)
-}
-}
-
-@Conference{Sarma04c
-,Author="Dipankar Sarma and Paul E. McKenney"
-,Title="Making {RCU} Safe for Deep Sub-Millisecond Response
-Realtime Applications"
-,Booktitle="Proceedings of the 2004 USENIX Annual Technical Conference
-(FREENIX Track)"
-,Publisher="USENIX Association"
-,year="2004"
-,month="June"
-,pages="182-191"
-,annotation="
-        Describes and compares a number of modifications to the Linux RCU
-        implementation that make it friendly to realtime applications.
-"
 }
 
 @phdthesis{PaulEdwardMcKenneyPhD
@@ -967,118 +529,17 @@ Oregon Health and Sciences University"
 ,note="Available:
 \url{http://www.rdrop.com/users/paulmck/RCU/RCUdissertation.2004.07.14e1.pdf}
 [Viewed October 15, 2004]"
-,annotation="
-        Describes RCU implementations and presents design patterns
-        corresponding to common uses of RCU in several operating-system
-        kernels.
-"
-}
-
-@unpublished{PaulEMcKenney2004rcu:dereference
-,Author="Dipankar Sarma"
-,Title="{Re: RCU : Abstracted RCU dereferencing [5/5]}"
-,month="August"
-,year="2004"
-,note="Available:
-\url{http://lkml.org/lkml/2004/8/6/237}
-[Viewed June 8, 2010]"
-,annotation="
-        Introduce rcu_dereference().
-"
-}
-
-@unpublished{JimHouston04a
-,Author="Jim Houston"
-,Title="{[RFC\&PATCH] Alternative {RCU} implementation}"
-,month="August"
-,year="2004"
-,note="Available:
-\url{http://lkml.org/lkml/2004/8/30/87}
-[Viewed February 17, 2005]"
-,annotation="
-        Uses active code in rcu_read_lock() and rcu_read_unlock() to
-        make RCU happen, allowing RCU to function on CPUs that do not
-        receive a scheduling-clock interrupt.
-"
-}
-
-@unpublished{TomHart04a
-,Author="Thomas E. Hart"
-,Title="Master's Thesis: Applying Lock-free Techniques to the {Linux} Kernel"
-,month="October"
-,year="2004"
-,note="Available:
-\url{http://www.cs.toronto.edu/~tomhart/masters_thesis.html}
-[Viewed October 15, 2004]"
-,annotation="
-        Proposes comparing RCU to lock-free methods for the Linux kernel.
-"
-}
-
-@unpublished{Vaddagiri04a
-,Author="Srivatsa Vaddagiri"
-,Title="Subject: [RFC] Use RCU for tcp\_ehash lookup"
-,month="October"
-,year="2004"
-,note="Available:
-\url{http://marc.theaimsgroup.com/?t=109395731700004&r=1&w=2}
-[Viewed October 18, 2004]"
-,annotation="
-        Srivatsa's RCU patch for tcp_ehash lookup.
-"
 }
 
-@unpublished{Thirumalai04a
-,Author="Ravikiran Thirumalai"
-,Title="Subject: [patchset] Lockfree fd lookup 0 of 5"
-,month="October"
-,year="2004"
-,note="Available:
-\url{http://marc.theaimsgroup.com/?t=109144217400003&r=1&w=2}
-[Viewed October 18, 2004]"
-,annotation="
-        Ravikiran's lockfree FD patch.
-"
-}
-
-@unpublished{Thirumalai04b
-,Author="Ravikiran Thirumalai"
-,Title="Subject: Re: [patchset] Lockfree fd lookup 0 of 5"
-,month="October"
-,year="2004"
-,note="Available:
-\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=109152521410459&w=2}
-[Viewed October 18, 2004]"
-,annotation="
-        Ravikiran's lockfree FD patch.
-"
-}
-
-@unpublished{PaulEMcKenney2004rcu:assign:pointer
-,Author="Paul E. McKenney"
-,Title="{[PATCH 1/3] RCU: \url{rcu_assign_pointer()} removal of memory barriers}"
-,month="October"
-,year="2004"
-,note="Available:
-\url{http://lkml.org/lkml/2004/10/23/241}
-[Viewed June 8, 2010]"
-,annotation="
-        Introduce rcu_assign_pointer().
-"
-}
-
-@unpublished{JamesMorris04a
-,Author="James Morris"
-,Title="{[PATCH 2/3] SELinux} scalability - convert {AVC} to {RCU}"
-,day="15"
-,month="November"
+@Conference{Sarma04c
+,Author="Dipankar Sarma and Paul E. McKenney"
+,Title="Making RCU Safe for Deep Sub-Millisecond Response Realtime Applications"
+,Booktitle="Proceedings of the 2004 USENIX Annual Technical Conference
+(FREENIX Track)"
+,Publisher="USENIX Association"
 ,year="2004"
-,note="Available:
-\url{http://marc.theaimsgroup.com/?l=linux-kernel&m=110054979416004&w=2}
-[Viewed December 10, 2004]"
-,annotation="
-        James Morris posts Kaigai Kohei's patch to LKML.
-"
+,month="June"
+,pages="182-191"
 }
 
 @unpublished{JamesMorris04b
@@ -1089,85 +550,6 @@ Oregon Health and Sciences University"
 ,note="Available:
 \url{http://www.livejournal.com/users/james_morris/2153.html}
 [Viewed December 10, 2004]"
-,annotation="
-        RCU helps SELinux performance.  ;-)  Made LWN.
-"
-}
-
-@unpublished{PaulMcKenney2005RCUSemantics
-,Author="Paul E. McKenney and Jonathan Walpole"
-,Title="{RCU} Semantics: A First Attempt"
-,month="January"
-,year="2005"
-,day="30"
-,note="Available:
-\url{http://www.rdrop.com/users/paulmck/RCU/rcu-semantics.2005.01.30a.pdf}
-[Viewed December 6, 2009]"
-,annotation="
-        Early derivation of RCU semantics.
-"
-}
-
-@unpublished{PaulMcKenney2005e
-,Author="Paul E. McKenney"
-,Title="Real-Time Preemption and {RCU}"
-,month="March"
-,year="2005"
-,day="17"
-,note="Available:
-\url{http://lkml.org/lkml/2005/3/17/199}
-[Viewed September 5, 2005]"
-,annotation="
-        First posting showing how RCU can be safely adapted for
-        preemptable RCU read side critical sections.
-"
-}
-
-@unpublished{EsbenNeilsen2005a
-,Author="Esben Neilsen"
-,Title="Re: Real-Time Preemption and {RCU}"
-,month="March"
-,year="2005"
-,day="18"
-,note="Available:
-\url{http://lkml.org/lkml/2005/3/18/122}
-[Viewed March 30, 2006]"
-,annotation="
-        Esben Neilsen suggests read-side suppression of grace-period
-        processing for crude-but-workable realtime RCU.  The downside
-        is indefinite grace periods...But this is OK for experimentation
-        and testing.
-"
-}
-
-@unpublished{TomHart05a
-,Author="Thomas E. Hart and Paul E. McKenney and Angela Demke Brown"
-,Title="Efficient Memory Reclamation is Necessary for Fast Lock-Free
-Data Structures"
-,month="March"
-,year="2005"
-,note="Available:
-\url{ftp://ftp.cs.toronto.edu/csrg-technical-reports/515/}
-[Viewed March 4, 2005]"
-,annotation="
-        Comparison of RCU, QBSR, and EBSR.  RCU wins for read-mostly
-        workloads.  ;-)
-"
-}
-
-@unpublished{JonCorbet2005DeprecateSyncKernel
-,Author="Jonathan Corbet"
-,Title="API change: synchronize_kernel() deprecated"
-,month="May"
-,day="3"
-,year="2005"
-,note="Available:
-\url{http://lwn.net/Articles/134484/}
-[Viewed May 3, 2005]"
-,annotation="
-        Jon Corbet describes deprecation of synchronize_kernel()
-        in favor of synchronize_rcu() and synchronize_sched().
-"
 }
 
 @unpublished{PaulMcKenney05a
@@ -1186,7 +568,7 @@ Data Structures"
 
 @conference{PaulMcKenney05b
 ,Author="Paul E. McKenney and Dipankar Sarma"
-,Title="Towards Hard Realtime Response from the {Linux} Kernel on {SMP} Hardware"
+,Title="Towards Hard Realtime Response from the Linux Kernel on SMP Hardware"
 ,Booktitle="linux.conf.au 2005"
 ,month="April"
 ,year="2005"
@@ -1196,103 +578,6 @@ Data Structures"
 [Viewed May 13, 2005]"
 ,annotation="
         Realtime turns into making RCU yet more realtime friendly.
-        http://lca2005.linux.org.au/Papers/Paul%20McKenney/Towards%20Hard%20Realtime%20Response%20from%20the%20Linux%20Kernel/LKS.2005.04.22a.pdf
-"
-}
-
-@unpublished{PaulEMcKenneyHomePage
-,Author="Paul E. McKenney"
-,Title="{Paul} {E.} {McKenney}"
-,month="May"
-,year="2005"
-,note="Available:
-\url{http://www.rdrop.com/users/paulmck/}
-[Viewed May 25, 2005]"
-,annotation="
-        Paul McKenney's home page.
-"
-}
-
-@unpublished{PaulEMcKenneyRCUPage
-,Author="Paul E. McKenney"
-,Title="Read-Copy Update {(RCU)}"
-,month="May"
-,year="2005"
-,note="Available:
-\url{http://www.rdrop.com/users/paulmck/RCU}
-[Viewed May 25, 2005]"
-,annotation="
-        Paul McKenney's RCU page.
-"
-}
-
-@unpublished{JosephSeigh2005a
-,Author="Joseph Seigh"
-,Title="{RCU}+{SMR} (hazard pointers)"
-,month="July"
-,year="2005"
-,note="Personal communication"
-,annotation="
-        Joe Seigh announcing his atomic-ptr-plus project.
-        http://sourceforge.net/projects/atomic-ptr-plus/
-"
-}
-
-@unpublished{JosephSeigh2005b
-,Author="Joseph Seigh"
-,Title="Lock-free synchronization primitives"
-,month="July"
-,day="6"
-,year="2005"
-,note="Available:
-\url{http://sourceforge.net/projects/atomic-ptr-plus/}
-[Viewed August 8, 2005]"
-,annotation="
-        Joe Seigh's atomic-ptr-plus project.
-"
-}
-
-@unpublished{PaulMcKenney2005c
-,Author="Paul E.McKenney"
-,Title="{[RFC,PATCH] RCU} and {CONFIG\_PREEMPT\_RT} sane patch"
-,month="August"
-,day="1"
-,year="2005"
-,note="Available:
-\url{http://lkml.org/lkml/2005/8/1/155}
-[Viewed March 14, 2006]"
-,annotation="
-        First operating counter-based realtime RCU patch posted to LKML.
-"
-}
-
-@unpublished{PaulMcKenney2005d
-,Author="Paul E. McKenney"
-,Title="Re: [Fwd: Re: [patch] Real-Time Preemption, -RT-2.6.13-rc4-V0.7.52-01]"
-,month="August"
-,day="8"
-,year="2005"
-,note="Available:
-\url{http://lkml.org/lkml/2005/8/8/108}
-[Viewed March 14, 2006]"
-,annotation="
-        First operating counter-based realtime RCU patch posted to LKML,
-        but fixed so that various unusual combinations of configuration
-        parameters all function properly.
-"
-}
-
-@unpublished{PaulMcKenney2005rcutorture
-,Author="Paul E. McKenney"
-,Title="{[PATCH]} {RCU} torture testing"
-,month="October"
-,day="1"
-,year="2005"
-,note="Available:
-\url{http://lkml.org/lkml/2005/10/1/70}
-[Viewed March 14, 2006]"
-,annotation="
-        First rcutorture patch.
 "
 }
 
@@ -1306,39 +591,22 @@ Distributed Processing Symposium"
 ,year="2006"
 ,day="25-29"
 ,address="Rhodes, Greece"
-,note="Available:
-\url{http://www.rdrop.com/users/paulmck/RCU/hart_ipdps06.pdf}
-[Viewed April 28, 2008]"
-,annotation="
-        Compares QSBR, HPBR, EBR, and lock-free reference counting.
-        http://www.cs.toronto.edu/~tomhart/perflab/ipdps06.tgz
-"
-}
-
-@unpublished{NickPiggin2006radixtree
-,Author="Nick Piggin"
-,Title="[patch 3/3] radix-tree: {RCU} lockless readside"
-,month="June"
-,day="20"
-,year="2006"
-,note="Available:
-\url{http://lkml.org/lkml/2006/6/20/238}
-[Viewed March 25, 2008]"
 ,annotation="
-        RCU-protected radix tree.
+        Compares QSBR (AKA "classic RCU"), HPBR, EBR, and lock-free
+        reference counting.
 "
 }
 
 @Conference{PaulEMcKenney2006b
 ,Author="Paul E. McKenney and Dipankar Sarma and Ingo Molnar and
 Suparna Bhattacharya"
-,Title="Extending {RCU} for Realtime and Embedded Workloads"
+,Title="Extending RCU for Realtime and Embedded Workloads"
 ,Booktitle="{Ottawa Linux Symposium}"
 ,Month="July"
 ,Year="2006"
 ,pages="v2 123-138"
 ,note="Available:
-\url{http://www.linuxsymposium.org/2006/view_abstract.php?content_key=184}
+\url{http://www.linuxsymposium.org/2006/index_2006.php}
 \url{http://www.rdrop.com/users/paulmck/RCU/OLSrtRCU.2006.08.11a.pdf}
 [Viewed January 1, 2007]"
 ,annotation="
@@ -1346,37 +614,6 @@ Suparna Bhattacharya"
 "
 }
 
-@unpublished{WikipediaRCU
-,Author="Paul E. McKenney and Chris Purcell and Algae and Ben Schumin and
-Gaius Cornelius and Qwertyus and Neil Conway and Sbw and Blainster and
-Canis Rufus and Zoicon5 and Anome and Hal Eisen"
-,Title="Read-Copy Update"
-,month="July"
-,day="8"
-,year="2006"
-,note="Available:
-\url{http://en.wikipedia.org/wiki/Read-copy-update}
-[Viewed August 21, 2006]"
-,annotation="
-        Wikipedia RCU page as of July 8 2006.
-"
-}
-
-@Conference{NickPiggin2006LocklessPageCache
-,Author="Nick Piggin"
-,Title="A Lockless Pagecache in Linux---Introduction, Progress, Performance"
-,Booktitle="{Ottawa Linux Symposium}"
-,Month="July"
-,Year="2006"
-,pages="v2 249-254"
-,note="Available:
-\url{http://www.linuxsymposium.org/2006/view_abstract.php?content_key=184}
-[Viewed January 11, 2009]"
-,annotation="
-        Uses RCU-protected radix tree for a lockless page cache.
-"
-}
-
 @unpublished{PaulEMcKenney2006c
 ,Author="Paul E. McKenney"
 ,Title="Sleepable {RCU}"
@@ -1400,301 +637,29 @@ Revised:
 ,day="18"
 ,year="2006"
 ,note="Available:
-\url{http://www.nada.kth.se/~snilsson/publications/TRASH/trash.pdf}
-[Viewed March 4, 2011]"
-,annotation="
-        RCU-protected dynamic trie-hash combination.
-"
-}
-
-@unpublished{ChristophHellwig2006RCU2SRCU
-,Author="Christoph Hellwig"
-,Title="Re: {[-mm PATCH 1/4]} {RCU}: split classic rcu"
-,month="September"
-,day="28"
-,year="2006"
-,note="Available:
-\url{http://lkml.org/lkml/2006/9/28/160}
-[Viewed March 27, 2008]"
-}
-
-@unpublished{PaulEMcKenneyRCUusagePage
-,Author="Paul E. McKenney"
-,Title="{RCU} {Linux} Usage"
-,month="October"
-,year="2006"
-,note="Available:
-\url{http://www.rdrop.com/users/paulmck/RCU/linuxusage.html}
-[Viewed January 14, 2007]"
-,annotation="
-        Paul McKenney's RCU page showing graphs plotting Linux-kernel
-        usage of RCU.
-"
-}
-
-@unpublished{PaulEMcKenneyRCUusageRawDataPage
-,Author="Paul E. McKenney"
-,Title="Read-Copy Update {(RCU)} Usage in {Linux} Kernel"
-,month="October"
-,year="2006"
-,note="Available:
-\url{http://www.rdrop.com/users/paulmck/RCU/linuxusage/rculocktab.html}
-[Viewed January 14, 2007]"
-,annotation="
-        Paul McKenney's RCU page showing Linux usage of RCU in tabular
-        form, with links to corresponding cscope databases.
-"
-}
-
-@unpublished{GauthamShenoy2006RCUrwlock
-,Author="Gautham R. Shenoy"
-,Title="[PATCH 4/5] lock\_cpu\_hotplug: Redesign - Lightweight implementation of lock\_cpu\_hotplug"
-,month="October"
-,year="2006"
-,day=26
-,note="Available:
-\url{http://lkml.org/lkml/2006/10/26/73}
-[Viewed January 26, 2009]"
-,annotation="
-        RCU-based reader-writer lock that allows readers to proceed with
-        no memory barriers or atomic instruction in absence of writers.
-        If writer do show up, readers must of course wait as required by
-        the semantics of reader-writer locking.  This is a recursive
-        lock.
-"
-}
-
-@unpublished{JensAxboe2006SlowSRCU
-,Author="Jens Axboe"
-,Title="Re: [patch] cpufreq: mark \url{cpufreq_tsc()} as
-\url{core_initcall_sync}"
-,month="November"
-,year="2006"
-,day=17
-,note="Available:
-\url{http://lkml.org/lkml/2006/11/17/56}
-[Viewed May 28, 2007]"
-,annotation="
-        SRCU's grace periods are too slow for Jens, even after a
-        factor-of-three speedup.
-        Sped-up version of SRCU at http://lkml.org/lkml/2006/11/17/359.
-"
-}
-
-@unpublished{OlegNesterov2006QRCU
-,Author="Oleg Nesterov"
-,Title="Re: [patch] cpufreq: mark {\tt cpufreq\_tsc()} as
-{\tt core\_initcall\_sync}"
-,month="November"
-,year="2006"
-,day=19
-,note="Available:
-\url{http://lkml.org/lkml/2006/11/19/69}
-[Viewed May 28, 2007]"
-,annotation="
-        First cut of QRCU.  Expanded/corrected versions followed.
-        Used to be OlegNesterov2007QRCU, now time-corrected.
-"
-}
-
-@unpublished{OlegNesterov2006aQRCU
-,Author="Oleg Nesterov"
-,Title="Re: [RFC, PATCH 1/2] qrcu: {"quick"} srcu implementation"
-,month="November"
-,year="2006"
-,day=30
-,note="Available:
-\url{http://lkml.org/lkml/2006/11/29/330}
-[Viewed November 26, 2008]"
-,annotation="
-        Expanded/corrected version of QRCU.
-        Used to be OlegNesterov2007aQRCU, now time-corrected.
-"
-}
-
-@unpublished{EvgeniyPolyakov2006RCUslowdown
-,Author="Evgeniy Polyakov"
-,Title="Badness in postponing work"
-,month="December"
-,year="2006"
-,day=05
-,note="Available:
-\url{http://www.ioremap.net/node/41}
-[Viewed October 28, 2008]"
-,annotation="
-        Using RCU as a pure delay leads to a 2.5x slowdown in skbs in
-        the Linux kernel.
-"
-}
-
-@inproceedings{ChrisMatthews2006ClusteredObjectsRCU
-,author = {Matthews, Chris and Coady, Yvonne and Appavoo, Jonathan}
-,title = {Portability events: a programming model for scalable system infrastructures}
-,booktitle = {PLOS '06: Proceedings of the 3rd workshop on Programming languages and operating systems}
-,year = {2006}
-,isbn = {1-59593-577-0}
-,pages = {11}
-,location = {San Jose, California}
-,doi = {http://doi.acm.org/10.1145/1215995.1216006}
-,publisher = {ACM}
-,address = {New York, NY, USA}
-,annotation={
-        Uses K42's RCU-like functionality to manage clustered-object
-        lifetimes.
-}}
-
-@article{DilmaDaSilva2006K42
-,author = {Silva, Dilma Da and Krieger, Orran and Wisniewski, Robert W. and Waterland, Amos and Tam, David and Baumann, Andrew}
-,title = {K42: an infrastructure for operating system research}
-,journal = {SIGOPS Oper. Syst. Rev.}
-,volume = {40}
-,number = {2}
-,year = {2006}
-,issn = {0163-5980}
-,pages = {34--42}
-,doi = {http://doi.acm.org/10.1145/1131322.1131333}
-,publisher = {ACM}
-,address = {New York, NY, USA}
-,annotation={
-        Describes relationship of K42 generations to RCU.
-}}
-
-# CoreyMinyard2007list_splice_rcu
-@unpublished{CoreyMinyard2007list:splice:rcu
-,Author="Corey Minyard and Paul E. McKenney"
-,Title="{[PATCH]} add an {RCU} version of list splicing"
-,month="January"
-,year="2007"
-,day=3
-,note="Available:
-\url{http://lkml.org/lkml/2007/1/3/112}
-[Viewed May 28, 2007]"
-,annotation="
-        Patch for list_splice_rcu().
-"
-}
-
-@unpublished{PaulEMcKenney2007rcubarrier
-,Author="Paul E. McKenney"
-,Title="{RCU} and Unloadable Modules"
-,month="January"
-,day="14"
-,year="2007"
-,note="Available:
-\url{http://lwn.net/Articles/217484/}
-[Viewed November 22, 2007]"
-,annotation="
-        LWN article introducing the rcu_barrier() primitive.
-"
-}
-
-@unpublished{PeterZijlstra2007SyncBarrier
-,Author="Peter Zijlstra and Ingo Molnar"
-,Title="{[PATCH 3/7]} barrier: a scalable synchonisation barrier"
-,month="January"
-,year="2007"
-,day=28
-,note="Available:
-\url{http://lkml.org/lkml/2007/1/28/34}
-[Viewed March 27, 2008]"
-,annotation="
-        RCU-like implementation for frequent updaters and rare readers(!).
-        Subsumed into QRCU.  Maybe...
-"
-}
-
-@unpublished{PaulEMcKenney2007BoostRCU
-,Author="Paul E. McKenney"
-,Title="Priority-Boosting {RCU} Read-Side Critical Sections"
-,month="February"
-,day="5"
-,year="2007"
-,note="Available:
-\url{http://lwn.net/Articles/220677/}
-Revised:
-\url{http://www.rdrop.com/users/paulmck/RCU/RCUbooststate.2007.04.16a.pdf}
-[Viewed September 7, 2007]"
-,annotation="
-        LWN article introducing RCU priority boosting.
-"
-}
-
-@unpublished{PaulMcKenney2007QRCUpatch
-,Author="Paul E. McKenney"
-,Title="{[PATCH]} {QRCU} with lockless fastpath"
-,month="February"
-,year="2007"
-,day=24
-,note="Available:
-\url{http://lkml.org/lkml/2007/2/25/18}
-[Viewed March 27, 2008]"
-,annotation="
-        Patch for QRCU supplying lock-free fast path.
-"
-}
-
-@article{JonathanAppavoo2007K42RCU
-,author = {Appavoo, Jonathan and Silva, Dilma Da and Krieger, Orran and Auslander, Marc and Ostrowski, Michal and Rosenburg, Bryan and Waterland, Amos and Wisniewski, Robert W. and Xenidis, Jimi and Stumm, Michael and Soares, Livio}
-,title = {Experience distributing objects in an SMMP OS}
-,journal = {ACM Trans. Comput. Syst.}
-,volume = {25}
-,number = {3}
-,year = {2007}
-,issn = {0734-2071}
-,pages = {6/1--6/52}
-,doi = {http://doi.acm.org/10.1145/1275517.1275518}
-,publisher = {ACM}
-,address = {New York, NY, USA}
-,annotation={
-        Role of RCU in K42.
-}}
-
-@conference{RobertOlsson2007Trash
-,Author="Robert Olsson and Stefan Nilsson"
-,Title="{TRASH}: A dynamic {LC}-trie and hash data structure"
-,booktitle="Workshop on High Performance Switching and Routing (HPSR'07)"
-,month="May"
-,year="2007"
-,note="Available:
-\url{http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4281239}
-[Viewed October 1, 2010]"
+\url{http://www.nada.kth.se/~snilsson/public/papers/trash/trash.pdf}
+[Viewed February 24, 2007]"
 ,annotation="
         RCU-protected dynamic trie-hash combination.
 "
 }
 
-@conference{PeterZijlstra2007ConcurrentPagecacheRCU
-,Author="Peter Zijlstra"
-,Title="Concurrent Pagecache"
-,Booktitle="Linux Symposium"
-,month="June"
-,year="2007"
-,address="Ottawa, Canada"
-,note="Available:
-\url{http://ols.108.redhat.com/2007/Reprints/zijlstra-Reprint.pdf}
-[Viewed April 14, 2008]"
-,annotation="
-        Page-cache modifications permitting RCU readers and concurrent
-        updates.
-"
-}
-
-@unpublished{PaulEMcKenney2007whatisRCU
-,Author="Paul E. McKenney"
-,Title="What is {RCU}?"
+@unpublished{ThomasEHart2007a
+,Author="Thomas E. Hart and Paul E. McKenney and Angela Demke Brown and Jonathan Walpole"
+,Title="Performance of memory reclamation for lockless synchronization"
+,journal="J. Parallel Distrib. Comput."
 ,year="2007"
-,month="07"
-,note="Available:
-\url{http://www.rdrop.com/users/paulmck/RCU/whatisRCU.html}
-[Viewed July 6, 2007]"
+,note="To appear in J. Parallel Distrib. Comput.
+       \url{doi=10.1016/j.jpdc.2007.04.010}"
 ,annotation={
-        Describes RCU in Linux kernel.
+        Compares QSBR (AKA "classic RCU"), HPBR, EBR, and lock-free
+        reference counting.  Journal version of ThomasEHart2006a.
 }
 }
 
 @unpublished{PaulEMcKenney2007QRCUspin
 ,Author="Paul E. McKenney"
-,Title="Using {Promela} and {Spin} to verify parallel algorithms"
+,Title="Using Promela and Spin to verify parallel algorithms"
 ,month="August"
 ,day="1"
 ,year="2007"
@@ -1704,50 +669,6 @@ Revised:
 ,annotation="
         LWN article describing Promela and spin, and also using Oleg
         Nesterov's QRCU as an example (with Paul McKenney's fastpath).
-        Merged patch at: http://lkml.org/lkml/2007/2/25/18
-"
-}
-
-@unpublished{PaulEMcKenney2007WG21DDOatomics
-,Author="Paul E. McKenney and Hans-J. Boehm and Lawrence Crowl"
-,Title="C++ Data-Dependency Ordering: Atomics and Memory Model"
-,month="August"
-,day="3"
-,year="2007"
-,note="Preprint:
-\url{http://open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2664.htm}
-[Viewed December 7, 2009]"
-,annotation="
-        RCU for C++, parts 1 and 2.
-"
-}
-
-@unpublished{PaulEMcKenney2007WG21DDOannotation
-,Author="Paul E. McKenney and Lawrence Crowl"
-,Title="C++ Data-Dependency Ordering: Function Annotation"
-,month="September"
-,day="18"
-,year="2008"
-,note="Preprint:
-\url{http://open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2782.htm}
-[Viewed December 7, 2009]"
-,annotation="
-        RCU for C++, part 2, updated many times.
-"
-}
-
-@unpublished{PaulEMcKenney2007PreemptibleRCUPatch
-,Author="Paul E. McKenney"
-,Title="[PATCH RFC 0/9] {RCU}: Preemptible {RCU}"
-,month="September"
-,day="10"
-,year="2007"
-,note="Available:
-\url{http://lkml.org/lkml/2007/9/10/213}
-[Viewed October 25, 2007]"
-,annotation="
-        Final patch for preemptable RCU to -rt.  (Later patches were
-        to mainline, eventually incorporated.)
 "
 }
 
@@ -1765,46 +686,10 @@ Revised:
 "
 }
 
-@article{ThomasEHart2007a
-,Author="Thomas E. Hart and Paul E. McKenney and Angela Demke Brown and Jonathan Walpole"
-,Title="Performance of memory reclamation for lockless synchronization"
-,journal="J. Parallel Distrib. Comput."
-,volume={67}
-,number="12"
-,year="2007"
-,issn="0743-7315"
-,pages="1270--1285"
-,doi="http://dx.doi.org/10.1016/j.jpdc.2007.04.010"
-,publisher="Academic Press, Inc."
-,address="Orlando, FL, USA"
-,annotation={
-        Compares QSBR, HPBR, EBR, and lock-free reference counting.
-        Journal version of ThomasEHart2006a.
-}
-}
-
-@unpublished{MathieuDesnoyers2007call:rcu:schedNeeded
-,Author="Mathieu Desnoyers"
-,Title="Re: [patch 1/2] {Linux} Kernel Markers - Support Multiple Probes"
-,month="December"
-,day="20"
-,year="2007"
-,note="Available:
-\url{http://lkml.org/lkml/2007/12/20/244}
-[Viewed March 27, 2008]"
-,annotation="
-        Request for call_rcu_sched() and rcu_barrier_sched().
-"
-}
-
-
 ########################################################################
 #
 #       "What is RCU?" LWN series.
 #
-#       http://lwn.net/Articles/262464/ (What is RCU, Fundamentally?)
-#       http://lwn.net/Articles/263130/ (What is RCU's Usage?)
-#       http://lwn.net/Articles/264090/ (What is RCU's API?)
 
 @unpublished{PaulEMcKenney2007WhatIsRCUFundamentally
 ,Author="Paul E. McKenney and Jonathan Walpole"
@@ -1838,7 +723,7 @@ Revised:
         3. RCU is a Bulk Reference-Counting Mechanism
         4. RCU is a Poor Man's Garbage Collector
         5. RCU is a Way of Providing Existence Guarantees
-        6. RCU is a Way of Waiting for Things to Finish
+        6. RCU is a Way of Waiting for Things to Finish 
 "
 }
 
@@ -1862,96 +747,20 @@ Revised:
 #
 ########################################################################
 
-
-@unpublished{SteveRostedt2008dyntickRCUpatch
-,Author="Steven Rostedt and Paul E. McKenney"
-,Title="{[PATCH]} add support for dynamic ticks and preempt rcu"
-,month="January"
-,day="29"
-,year="2008"
-,note="Available:
-\url{http://lkml.org/lkml/2008/1/29/208}
-[Viewed March 27, 2008]"
-,annotation="
-        Patch that prevents preemptible RCU from unnecessarily waking
-        up dynticks-idle CPUs.
-"
-}
-
-@unpublished{PaulEMcKenney2008LKMLDependencyOrdering
-,Author="Paul E. McKenney"
-,Title="Re: [PATCH 02/22 -v7] Add basic support for gcc profiler instrumentation"
-,month="February"
-,day="1"
-,year="2008"
-,note="Available:
-\url{http://lkml.org/lkml/2008/2/2/255}
-[Viewed October 18, 2008]"
-,annotation="
-        Explanation of compilers violating dependency ordering.
-"
-}
-
-@Conference{PaulEMcKenney2008Beijing
-,Author="Paul E. McKenney"
-,Title="Introducing Technology Into {Linux} Or:
-Introducing your technology Into {Linux} will require introducing a
-lot of {Linux} into your technology!!!"
-,Booktitle="2008 Linux Developer Symposium - China"
-,Publisher="OSS China"
-,Month="February"
-,Year="2008"
-,Address="Beijing, China"
-,note="Available:
-\url{http://www.rdrop.com/users/paulmck/RCU/TechIntroLinux.2008.02.19a.pdf}
-[Viewed August 12, 2008]"
-}
-
-@unpublished{PaulEMcKenney2008dynticksRCU
-,Author="Paul E. McKenney and Steven Rostedt"
-,Title="Integrating and Validating dynticks and Preemptable RCU"
-,month="April"
-,day="24"
-,year="2008"
-,note="Available:
-\url{http://lwn.net/Articles/279077/}
-[Viewed April 24, 2008]"
-,annotation="
-        Describes use of Promela and Spin to validate (and fix!) the
-        dynticks/RCU interface.
-"
-}
-
 @article{DinakarGuniguntala2008IBMSysJ
 ,author="D. Guniguntala and P. E. McKenney and J. Triplett and J. Walpole"
 ,title="The read-copy-update mechanism for supporting real-time applications on shared-memory multiprocessor systems with {Linux}"
 ,Year="2008"
-,Month="April-June"
+,Month="April"
 ,journal="IBM Systems Journal"
 ,volume="47"
 ,number="2"
-,pages="221-236"
+,pages="@@-@@"
 ,annotation="
         RCU, realtime RCU, sleepable RCU, performance.
 "
 }
 
-@unpublished{LaiJiangshan2008NewClassicAlgorithm
-,Author="Lai Jiangshan"
-,Title="[{RFC}][{PATCH}] rcu classic: new algorithm for callbacks-processing"
-,month="June"
-,day="3"
-,year="2008"
-,note="Available:
-\url{http://lkml.org/lkml/2008/6/2/539}
-[Viewed December 10, 2008]"
-,annotation="
-        Updated RCU classic algorithm.  Introduced multi-tailed list
-        for RCU callbacks and also pulling common code into
-        __call_rcu().
-"
-}
-
 @article{PaulEMcKenney2008RCUOSR
 ,author="Paul E. McKenney and Jonathan Walpole"
 ,title="Introducing technology into the {Linux} kernel: a case study"
@@ -1969,52 +778,6 @@ lot of {Linux} into your technology!!!"
 }
 }
 
-@unpublished{ManfredSpraul2008StateMachineRCU
-,Author="Manfred Spraul"
-,Title="[{RFC}, {PATCH}] state machine based rcu"
-,month="August"
-,day="21"
-,year="2008"
-,note="Available:
-\url{http://lkml.org/lkml/2008/8/21/336}
-[Viewed December 8, 2008]"
-,annotation="
-        State-based RCU.  One key thing that this patch does is to
-        separate the dynticks handling of NMIs and IRQs.
-"
-}
-
-@unpublished{ManfredSpraul2008dyntickIRQNMI
-,Author="Manfred Spraul"
-,Title="Re: [{RFC}, {PATCH}] v4 scalable classic {RCU} implementation"
-,month="September"
-,day="6"
-,year="2008"
-,note="Available:
-\url{http://lkml.org/lkml/2008/9/6/86}
-[Viewed December 8, 2008]"
-,annotation="
-        Manfred notes a fix required to my attempt to separate irq
-        and NMI processing for hierarchical RCU's dynticks interface.
-"
-}
-
-@techreport{PaulEMcKenney2008cyclicRCU
-,author="Paul E. McKenney"
-,title="Efficient Support of Consistent Cyclic Search With Read-Copy Update"
-,institution="US Patent and Trademark Office"
-,address="Washington, DC"
-,year="2008"
-,number="US Patent 7,426,511"
-,month="September"
-,pages="23"
-,annotation="
-        Maintains an additional level of indirection to allow
-        readers to confine themselves to the desired snapshot of the
-        data structure.  Only permits one update at a time.
-"
-}
-
 @unpublished{PaulEMcKenney2008HierarchicalRCU
 ,Author="Paul E. McKenney"
 ,Title="Hierarchical {RCU}"
@@ -2030,21 +793,6 @@ lot of {Linux} into your technology!!!"
 "
 }
 
-@unpublished{PaulEMcKenney2009BloatwatchRCU
-,Author="Paul E. McKenney"
-,Title="Re: [PATCH fyi] RCU: the bloatwatch edition"
-,month="January"
-,day="14"
-,year="2009"
-,note="Available:
-\url{http://lkml.org/lkml/2009/1/14/449}
-[Viewed January 15, 2009]"
-,annotation="
-        Small-footprint implementation of RCU for uniprocessor
-        embedded applications -- and also for exposition purposes.
-"
-}
-
 @conference{PaulEMcKenney2009MaliciousURCU
 ,Author="Paul E. McKenney"
 ,Title="Using a Malicious User-Level {RCU} to Torture {RCU}-Based Algorithms"
@@ -2068,17 +816,15 @@ lot of {Linux} into your technology!!!"
 ,year="2009"
 ,note="Available:
 \url{http://lkml.org/lkml/2009/2/5/572}
-\url{http://lttng.org/urcu}
+\url{git://lttng.org/userspace-rcu.git}
 [Viewed February 20, 2009]"
 ,annotation="
         Mathieu Desnoyers's user-space RCU implementation.
         git://lttng.org/userspace-rcu.git
-        http://lttng.org/cgi-bin/gitweb.cgi?p=userspace-rcu.git
-        http://lttng.org/urcu
 "
 }
 
-@unpublished{PaulEMcKenney2009LWNBloatWatchRCU
+@unpublished{PaulEMcKenney2009BloatWatchRCU
 ,Author="Paul E. McKenney"
 ,Title="{RCU}: The {Bloatwatch} Edition"
 ,month="March"
@@ -2106,29 +852,14 @@ lot of {Linux} into your technology!!!"
 "
 }
 
-@unpublished{PaulEMcKenney2009fastRTRCU
-,Author="Paul E. McKenney"
-,Title="[{PATCH} {RFC} -tip 0/4] {RCU} cleanups and simplified preemptable {RCU}"
-,month="July"
-,day="23"
-,year="2009"
-,note="Available:
-\url{http://lkml.org/lkml/2009/7/23/294}
-[Viewed August 15, 2009]"
-,annotation="
-        First posting of simple and fast preemptable RCU.
-"
-}
-
-@InProceedings{JoshTriplett2009RPHash
+@unpublished{JoshTriplett2009RPHash
 ,Author="Josh Triplett"
 ,Title="Scalable concurrent hash tables via relativistic programming"
 ,month="September"
 ,year="2009"
-,booktitle="Linux Plumbers Conference 2009"
+,note="Linux Plumbers Conference presentation"
 ,annotation="
         RP fun with hash tables.
-        See also JoshTriplett2010RPHash
 "
 }
 
@@ -2141,323 +872,4 @@ lot of {Linux} into your technology!!!"
 ,note="Available:
 \url{http://www.lttng.org/pub/thesis/desnoyers-dissertation-2009-12.pdf}
 [Viewed December 9, 2009]"
-,annotation={
-        Chapter 6 (page 97) covers user-level RCU.
-}
-}
-
-@unpublished{RelativisticProgrammingWiki
-,Author="Josh Triplett and Paul E. McKenney and Jonathan Walpole"
-,Title="Relativistic Programming"
-,month="September"
-,year="2009"
-,note="Available:
-\url{http://wiki.cs.pdx.edu/rp/}
-[Viewed December 9, 2009]"
-,annotation="
-        Main Relativistic Programming Wiki.
-"
-}
-
-@conference{PaulEMcKenney2009DeterministicRCU
-,Author="Paul E. McKenney"
-,Title="Deterministic Synchronization in Multicore Systems: the Role of {RCU}"
-,Booktitle="Eleventh Real Time Linux Workshop"
-,month="September"
-,year="2009"
-,address="Dresden, Germany"
-,note="Available:
-\url{http://www.rdrop.com/users/paulmck/realtime/paper/DetSyncRCU.2009.08.18a.pdf}
-[Viewed January 14, 2009]"
-}
-
-@unpublished{PaulEMcKenney2009HuntingHeisenbugs
-,Author="Paul E. McKenney"
-,Title="Hunting Heisenbugs"
-,month="November"
-,year="2009"
-,day="1"
-,note="Available:
-\url{http://paulmck.livejournal.com/14639.html}
-[Viewed June 4, 2010]"
-,annotation="
-        Day-one bug in Tree RCU that took forever to track down.
-"
-}
-
-@unpublished{MathieuDesnoyers2009defer:rcu
-,Author="Mathieu Desnoyers"
-,Title="Kernel RCU: shrink the size of the struct rcu\_head"
-,month="December"
-,year="2009"
-,note="Available:
-\url{http://lkml.org/lkml/2009/10/18/129}
-[Viewed December 29, 2009]"
-,annotation="
-        Mathieu proposed defer_rcu() with fixed-size per-thread pool
-        of RCU callbacks.
-"
-}
-
-@unpublished{MathieuDesnoyers2009VerifPrePub
-,Author="Mathieu Desnoyers and Paul E. McKenney and Michel R. Dagenais"
-,Title="Multi-Core Systems Modeling for Formal Verification of Parallel Algorithms"
-,month="December"
-,year="2009"
-,note="Submitted to IEEE TPDS"
-,annotation="
-        OOMem model for Mathieu's user-level RCU mechanical proof of
-        correctness.
-"
-}
-
-@unpublished{MathieuDesnoyers2009URCUPrePub
-,Author="Mathieu Desnoyers and Paul E. McKenney and Alan Stern and Michel R. Dagenais and Jonathan Walpole"
-,Title="User-Level Implementations of Read-Copy Update"
-,month="December"
-,year="2010"
-,url=\url{http://www.computer.org/csdl/trans/td/2012/02/ttd2012020375-abs.html}
-,annotation="
-        RCU overview, desiderata, semi-formal semantics, user-level RCU
-        usage scenarios, three classes of RCU implementation, wait-free
-        RCU updates, RCU grace-period batching, update overhead,
-        http://www.rdrop.com/users/paulmck/RCU/urcu-main-accepted.2011.08.30a.pdf
-        http://www.rdrop.com/users/paulmck/RCU/urcu-supp-accepted.2011.08.30a.pdf
-        Superseded by MathieuDesnoyers2012URCU.
-"
-}
-
-@inproceedings{HariKannan2009DynamicAnalysisRCU
-,author = {Kannan, Hari}
-,title = {Ordering decoupled metadata accesses in multiprocessors}
-,booktitle = {MICRO 42: Proceedings of the 42nd Annual IEEE/ACM International Symposium on Microarchitecture}
-,year = {2009}
-,isbn = {978-1-60558-798-1}
-,pages = {381--390}
-,location = {New York, New York}
-,doi = {http://doi.acm.org/10.1145/1669112.1669161}
-,publisher = {ACM}
-,address = {New York, NY, USA}
-,annotation={
-        Uses RCU to protect metadata used in dynamic analysis.
-}}
-
-@conference{PaulEMcKenney2010SimpleOptRCU
-,Author="Paul E. McKenney"
-,Title="Simplicity Through Optimization"
-,Booktitle="linux.conf.au 2010"
-,month="January"
-,year="2010"
-,address="Wellington, New Zealand"
-,note="Available:
-\url{http://www.rdrop.com/users/paulmck/RCU/SimplicityThruOptimization.2010.01.21f.pdf}
-[Viewed October 10, 2010]"
-,annotation="
-        TREE_PREEMPT_RCU optimizations greatly simplified the old
-        PREEMPT_RCU implementation.
-"
-}
-
-@unpublished{PaulEMcKenney2010LockdepRCU
-,Author="Paul E. McKenney"
-,Title="Lockdep-{RCU}"
-,month="February"
-,year="2010"
-,day="1"
-,note="Available:
-\url{https://lwn.net/Articles/371986/}
-[Viewed June 4, 2010]"
-,annotation="
-        CONFIG_PROVE_RCU, or at least an early version.
-"
-}
-
-@unpublished{AviKivity2010KVM2RCU
-,Author="Avi Kivity"
-,Title="[{PATCH} 37/40] {KVM}: Bump maximum vcpu count to 64"
-,month="February"
-,year="2010"
-,note="Available:
-\url{http://www.mail-archive.com/kvm@vger.kernel.org/msg28640.html}
-[Viewed March 20, 2010]"
-,annotation="
-        Use of RCU permits KVM to increase the size of guest OSes from
-        16 CPUs to 64 CPUs.
-"
-}
-
-@unpublished{HerbertXu2010RCUResizeHash
-,Author="Herbert Xu"
-,Title="bridge: Add core IGMP snooping support"
-,month="February"
-,year="2010"
-,note="Available:
-\url{http://kerneltrap.com/mailarchive/linux-netdev/2010/2/26/6270589}
-[Viewed March 20, 2011]"
-,annotation={
-        Use a pair of list_head structures to support RCU-protected
-        resizable hash tables.
-}}
-
-@article{JoshTriplett2010RPHash
-,author="Josh Triplett and Paul E. McKenney and Jonathan Walpole"
-,title="Scalable Concurrent Hash Tables via Relativistic Programming"
-,journal="ACM Operating Systems Review"
-,year=2010
-,volume=44
-,number=3
-,month="July"
-,annotation={
-        RP fun with hash tables.
-        http://portal.acm.org/citation.cfm?id=1842733.1842750
-}}
-
-@unpublished{PaulEMcKenney2010RCUAPI
-,Author="Paul E. McKenney"
-,Title="The {RCU} {API}, 2010 Edition"
-,month="December"
-,day="8"
-,year="2010"
-,note="Available:
-\url{http://lwn.net/Articles/418853/}
-[Viewed December 8, 2010]"
-,annotation="
-        Includes updated software-engineering features.
-"
-}
-
-@mastersthesis{AndrejPodzimek2010masters
-,author="Andrej Podzimek"
-,title="Read-Copy-Update for OpenSolaris"
-,school="Charles University in Prague"
-,year="2010"
-,note="Available:
-\url{https://andrej.podzimek.org/thesis.pdf}
-[Viewed January 31, 2011]"
-,annotation={
-        Reviews RCU implementations and creates a few for OpenSolaris.
-        Drives quiescent-state detection from RCU read-side primitives,
-        in a manner roughly similar to that of Jim Houston.
-}}
-
-@unpublished{LinusTorvalds2011Linux2:6:38:rc1:NPigginVFS
-,Author="Linus Torvalds"
-,Title="Linux 2.6.38-rc1"
-,month="January"
-,year="2011"
-,note="Available:
-\url{https://lkml.org/lkml/2011/1/18/322}
-[Viewed March 4, 2011]"
-,annotation={
-        "The RCU-based name lookup is at the other end of the spectrum - the
-        absolute anti-gimmick. It's some seriously good stuff, and gets rid of
-        the last main global lock that really tends to hurt some kernel loads.
-        The dentry lock is no longer a big serializing issue. What's really
-        nice about it is that it actually improves performance a lot even for
-        single-threaded loads (on an SMP kernel), because it gets rid of some
-        of the most expensive parts of path component lookup, which was the
-        d_lock on every component lookup. So I'm seeing improvements of 30-50%
-        on some seriously pathname-lookup intensive loads."
-}}
-
-@techreport{JoshTriplett2011RPScalableCorrectOrdering
-,author = {Josh Triplett and Philip W. Howard and Paul E. McKenney and Jonathan Walpole}
-,title = {Scalable Correct Memory Ordering via Relativistic Programming}
-,year = {2011}
-,number = {11-03}
-,institution = {Portland State University}
-,note = {\url{http://www.cs.pdx.edu/pdfs/tr1103.pdf}}
-}
-
-@inproceedings{PhilHoward2011RCUTMRBTree
-,author = {Philip W. Howard and Jonathan Walpole}
-,title = {A Relativistic Enhancement to Software Transactional Memory}
-,booktitle = {Proceedings of the 3rd USENIX conference on Hot topics in parallelism}
-,series = {HotPar'11}
-,year = {2011}
-,location = {Berkeley, CA}
-,pages = {1--6}
-,numpages = {6}
-,url = {http://www.usenix.org/event/hotpar11/tech/final_files/Howard.pdf}
-,publisher = {USENIX Association}
-,address = {Berkeley, CA, USA}
-}
-
-@techreport{PaulEMcKenney2011cyclicparallelRCU
-,author="Paul E. McKenney and Jonathan Walpole"
-,title="Efficient Support of Consistent Cyclic Search With Read-Copy Update and Parallel Updates"
-,institution="US Patent and Trademark Office"
-,address="Washington, DC"
-,year="2011"
-,number="US Patent 7,953,778"
-,month="May"
-,pages="34"
-,annotation="
-        Maintains an array of generation numbers to track in-flight
-        updates and keeps an additional level of indirection to allow
-        readers to confine themselves to the desired snapshot of the
-        data structure.
-"
-}
-
-@inproceedings{Triplett:2011:RPHash
-,author = {Triplett, Josh and McKenney, Paul E. and Walpole, Jonathan}
-,title = {Resizable, Scalable, Concurrent Hash Tables via Relativistic Programming}
-,booktitle = {Proceedings of the 2011 USENIX Annual Technical Conference}
-,month = {June}
-,year = {2011}
-,pages = {145--158}
-,numpages = {14}
-,url={http://www.usenix.org/event/atc11/tech/final_files/atc11_proceedings.pdf}
-,publisher = {The USENIX Association}
-,address = {Portland, OR USA}
-}
-
-@unpublished{PaulEMcKenney2011RCU3.0trainwreck
-,Author="Paul E. McKenney"
-,Title="3.0 and {RCU:} what went wrong"
-,month="July"
-,day="27"
-,year="2011"
-,note="Available:
-\url{http://lwn.net/Articles/453002/}
-[Viewed July 27, 2011]"
-,annotation="
-        Analysis of the RCU trainwreck in Linux kernel 3.0.
-"
-}
-
-@unpublished{NeilBrown2011MeetTheLockers
-,Author="Neil Brown"
-,Title="Meet the Lockers"
-,month="August"
-,day="3"
-,year="2011"
-,note="Available:
-\url{http://lwn.net/Articles/453685/}
-[Viewed September 2, 2011]"
-,annotation="
-        The Locker family as an analogy for locking, reference counting,
-        RCU, and seqlock.
-"
-}
-
-@article{MathieuDesnoyers2012URCU
-,Author="Mathieu Desnoyers and Paul E. McKenney and Alan Stern and Michel R. Dagenais and Jonathan Walpole"
-,Title="User-Level Implementations of Read-Copy Update"
-,journal="IEEE Transactions on Parallel and Distributed Systems"
-,volume={23}
-,year="2012"
-,issn="1045-9219"
-,pages="375-382"
-,doi="http://doi.ieeecomputersociety.org/10.1109/TPDS.2011.159"
-,publisher="IEEE Computer Society"
-,address="Los Alamitos, CA, USA"
-,annotation={
-        RCU overview, desiderata, semi-formal semantics, user-level RCU
-        usage scenarios, three classes of RCU implementation, wait-free
-        RCU updates, RCU grace-period batching, update overhead,
-        http://www.rdrop.com/users/paulmck/RCU/urcu-main-accepted.2011.08.30a.pdf
-        http://www.rdrop.com/users/paulmck/RCU/urcu-supp-accepted.2011.08.30a.pdf
-}
 }
diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
index 31ef8fe07f8..0c134f8afc6 100644
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@@ -162,9 +162,9 @@ over a rather long period of time, but improvements are always welcome!
                 when publicizing a pointer to a structure that can
                 be traversed by an RCU read-side critical section.
 
-5.      If call_rcu(), or a related primitive such as call_rcu_bh(),
-        call_rcu_sched(), or call_srcu() is used, the callback function
-        must be written to be called from softirq context.  In particular,
+5.      If call_rcu(), or a related primitive such as call_rcu_bh() or
+        call_rcu_sched(), is used, the callback function must be
+        written to be called from softirq context.  In particular,
         it cannot block.
 
 6.      Since synchronize_rcu() can block, it cannot be called from
@@ -180,20 +180,6 @@ over a rather long period of time, but improvements are always welcome!
         operations that would not normally be undertaken while a real-time
         workload is running.
 
-        In particular, if you find yourself invoking one of the expedited
-        primitives repeatedly in a loop, please do everyone a favor:
-        Restructure your code so that it batches the updates, allowing
-        a single non-expedited primitive to cover the entire batch.
-        This will very likely be faster than the loop containing the
-        expedited primitive, and will be much much easier on the rest
-        of the system, especially to real-time workloads running on
-        the rest of the system.
-
-        In addition, it is illegal to call the expedited forms from
-        a CPU-hotplug notifier, or while holding a lock that is acquired
-        by a CPU-hotplug notifier.  Failing to observe this restriction
-        will result in deadlock.
-
 7.      If the updater uses call_rcu() or synchronize_rcu(), then the
         corresponding readers must use rcu_read_lock() and
         rcu_read_unlock().  If the updater uses call_rcu_bh() or
@@ -202,12 +188,11 @@ over a rather long period of time, but improvements are always welcome!
         updater uses call_rcu_sched() or synchronize_sched(), then
         the corresponding readers must disable preemption, possibly
         by calling rcu_read_lock_sched() and rcu_read_unlock_sched().
-        If the updater uses synchronize_srcu() or call_srcu(),
-        the the corresponding readers must use srcu_read_lock() and
-        srcu_read_unlock(), and with the same srcu_struct.  The rules for
-        the expedited primitives are the same as for their non-expedited
-        counterparts.  Mixing things up will result in confusion and
-        broken kernels.
+        If the updater uses synchronize_srcu(), the the corresponding
+        readers must use srcu_read_lock() and srcu_read_unlock(),
+        and with the same srcu_struct.  The rules for the expedited
+        primitives are the same as for their non-expedited counterparts.
+        Mixing things up will result in confusion and broken kernels.
 
         One exception to this rule: rcu_read_lock() and rcu_read_unlock()
         may be substituted for rcu_read_lock_bh() and rcu_read_unlock_bh()
@@ -271,14 +256,15 @@ over a rather long period of time, but improvements are always welcome!
         The same cautions apply to call_rcu_bh() and call_rcu_sched().
 
 9.      All RCU list-traversal primitives, which include
-        rcu_dereference(), list_for_each_entry_rcu(), and
-        list_for_each_safe_rcu(), must be either within an RCU read-side
-        critical section or must be protected by appropriate update-side
-        locks.  RCU read-side critical sections are delimited by
-        rcu_read_lock() and rcu_read_unlock(), or by similar primitives
-        such as rcu_read_lock_bh() and rcu_read_unlock_bh(), in which
-        case the matching rcu_dereference() primitive must be used in
-        order to keep lockdep happy, in this case, rcu_dereference_bh().
+        rcu_dereference(), list_for_each_entry_rcu(),
+        list_for_each_continue_rcu(), and list_for_each_safe_rcu(),
+        must be either within an RCU read-side critical section or
+        must be protected by appropriate update-side locks.  RCU
+        read-side critical sections are delimited by rcu_read_lock()
+        and rcu_read_unlock(), or by similar primitives such as
+        rcu_read_lock_bh() and rcu_read_unlock_bh(), in which case
+        the matching rcu_dereference() primitive must be used in order
+        to keep lockdep happy, in this case, rcu_dereference_bh().
 
         The reason that it is permissible to use RCU list-traversal
         primitives when the update-side lock is held is that doing so
@@ -309,12 +295,6 @@ over a rather long period of time, but improvements are always welcome!
         code under the influence of preempt_disable(), you instead
         need to use synchronize_irq() or synchronize_sched().
 
-        This same limitation also applies to synchronize_rcu_bh()
-        and synchronize_srcu(), as well as to the asynchronous and
-        expedited forms of the three primitives, namely call_rcu(),
-        call_rcu_bh(), call_srcu(), synchronize_rcu_expedited(),
-        synchronize_rcu_bh_expedited(), and synchronize_srcu_expedited().
-
 12.     Any lock acquired by an RCU callback must be acquired elsewhere
         with softirq disabled, e.g., via spin_lock_irqsave(),
         spin_lock_bh(), etc.  Failing to disable irq on a given
@@ -339,28 +319,22 @@ over a rather long period of time, but improvements are always welcome!
         victim CPU from ever going offline.)
 
 14.     SRCU (srcu_read_lock(), srcu_read_unlock(), srcu_dereference(),
-        synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu())
-        may only be invoked from process context.  Unlike other forms of
-        RCU, it -is- permissible to block in an SRCU read-side critical
-        section (demarked by srcu_read_lock() and srcu_read_unlock()),
-        hence the "SRCU": "sleepable RCU".  Please note that if you
-        don't need to sleep in read-side critical sections, you should be
-        using RCU rather than SRCU, because RCU is almost always faster
-        and easier to use than is SRCU.
-
-        If you need to enter your read-side critical section in a
-        hardirq or exception handler, and then exit that same read-side
-        critical section in the task that was interrupted, then you need
-        to srcu_read_lock_raw() and srcu_read_unlock_raw(), which avoid
-        the lockdep checking that would otherwise this practice illegal.
+        synchronize_srcu(), and synchronize_srcu_expedited()) may only
+        be invoked from process context.  Unlike other forms of RCU, it
+        -is- permissible to block in an SRCU read-side critical section
+        (demarked by srcu_read_lock() and srcu_read_unlock()), hence the
+        "SRCU": "sleepable RCU".  Please note that if you don't need
+        to sleep in read-side critical sections, you should be using
+        RCU rather than SRCU, because RCU is almost always faster and
+        easier to use than is SRCU.
 
         Also unlike other forms of RCU, explicit initialization
         and cleanup is required via init_srcu_struct() and
         cleanup_srcu_struct().  These are passed a "struct srcu_struct"
         that defines the scope of a given SRCU domain.  Once initialized,
         the srcu_struct is passed to srcu_read_lock(), srcu_read_unlock()
-        synchronize_srcu(), synchronize_srcu_expedited(), and call_srcu().
-        A given synchronize_srcu() waits only for SRCU read-side critical
+        synchronize_srcu(), and synchronize_srcu_expedited().  A given
+        synchronize_srcu() waits only for SRCU read-side critical
         sections governed by srcu_read_lock() and srcu_read_unlock()
         calls that have been passed the same srcu_struct.  This property
         is what makes sleeping read-side critical sections tolerable --
@@ -380,7 +354,7 @@ over a rather long period of time, but improvements are always welcome!
         requiring SRCU's read-side deadlock immunity or low read-side
         realtime latency.
 
-        Note that, rcu_assign_pointer() relates to SRCU just as it does
+        Note that, rcu_assign_pointer() relates to SRCU just as they do
         to other forms of RCU.
 
 15.     The whole point of call_rcu(), synchronize_rcu(), and friends
diff --git a/Documentation/RCU/listRCU.txt b/Documentation/RCU/listRCU.txt
index adb5a378284..4349c1487e9 100644
--- a/Documentation/RCU/listRCU.txt
+++ b/Documentation/RCU/listRCU.txt
@@ -205,7 +205,7 @@ RCU ("read-copy update") its name.  The RCU code is as follows:
                                 audit_copy_rule(&ne->rule, &e->rule);
                                 ne->rule.action = newaction;
                                 ne->rule.file_count = newfield_count;
-                                list_replace_rcu(&e->list, &ne->list);
+                                list_replace_rcu(e, ne);
                                 call_rcu(&e->rcu, audit_free_rule);
                                 return 0;
                         }
diff --git a/Documentation/RCU/lockdep-splat.txt b/Documentation/RCU/lockdep-splat.txt
deleted file mode 100644
index bf906114282..00000000000
--- a/Documentation/RCU/lockdep-splat.txt
+++ /dev/null
@@ -1,110 +0,0 @@
-Lockdep-RCU was added to the Linux kernel in early 2010
-(http://lwn.net/Articles/371986/).  This facility checks for some common
-misuses of the RCU API, most notably using one of the rcu_dereference()
-family to access an RCU-protected pointer without the proper protection.
-When such misuse is detected, an lockdep-RCU splat is emitted.
-
-The usual cause of a lockdep-RCU slat is someone accessing an
-RCU-protected data structure without either (1) being in the right kind of
-RCU read-side critical section or (2) holding the right update-side lock.
-This problem can therefore be serious: it might result in random memory
-overwriting or worse.  There can of course be false positives, this
-being the real world and all that.
-
-So let's look at an example RCU lockdep splat from 3.0-rc5, one that
-has long since been fixed:
-
-===============================
-[ INFO: suspicious RCU usage. ]
--------------------------------
-block/cfq-iosched.c:2776 suspicious rcu_dereference_protected() usage!
-
-other info that might help us debug this:
-
-
-rcu_scheduler_active = 1, debug_locks = 0
-3 locks held by scsi_scan_6/1552:
- #0:  (&shost->scan_mutex){+.+.+.}, at: [<ffffffff8145efca>]
-scsi_scan_host_selected+0x5a/0x150
- #1:  (&eq->sysfs_lock){+.+...}, at: [<ffffffff812a5032>]
-elevator_exit+0x22/0x60
- #2:  (&(&q->__queue_lock)->rlock){-.-...}, at: [<ffffffff812b6233>]
-cfq_exit_queue+0x43/0x190
-
-stack backtrace:
-Pid: 1552, comm: scsi_scan_6 Not tainted 3.0.0-rc5 #17
-Call Trace:
- [<ffffffff810abb9b>] lockdep_rcu_dereference+0xbb/0xc0
- [<ffffffff812b6139>] __cfq_exit_single_io_context+0xe9/0x120
- [<ffffffff812b626c>] cfq_exit_queue+0x7c/0x190
- [<ffffffff812a5046>] elevator_exit+0x36/0x60
- [<ffffffff812a802a>] blk_cleanup_queue+0x4a/0x60
- [<ffffffff8145cc09>] scsi_free_queue+0x9/0x10
- [<ffffffff81460944>] __scsi_remove_device+0x84/0xd0
- [<ffffffff8145dca3>] scsi_probe_and_add_lun+0x353/0xb10
- [<ffffffff817da069>] ? error_exit+0x29/0xb0
- [<ffffffff817d98ed>] ? _raw_spin_unlock_irqrestore+0x3d/0x80
- [<ffffffff8145e722>] __scsi_scan_target+0x112/0x680
- [<ffffffff812c690d>] ? trace_hardirqs_off_thunk+0x3a/0x3c
- [<ffffffff817da069>] ? error_exit+0x29/0xb0
- [<ffffffff812bcc60>] ? kobject_del+0x40/0x40
- [<ffffffff8145ed16>] scsi_scan_channel+0x86/0xb0
- [<ffffffff8145f0b0>] scsi_scan_host_selected+0x140/0x150
- [<ffffffff8145f149>] do_scsi_scan_host+0x89/0x90
- [<ffffffff8145f170>] do_scan_async+0x20/0x160
- [<ffffffff8145f150>] ? do_scsi_scan_host+0x90/0x90
- [<ffffffff810975b6>] kthread+0xa6/0xb0
- [<ffffffff817db154>] kernel_thread_helper+0x4/0x10
- [<ffffffff81066430>] ? finish_task_switch+0x80/0x110
- [<ffffffff817d9c04>] ? retint_restore_args+0xe/0xe
- [<ffffffff81097510>] ? __init_kthread_worker+0x70/0x70
- [<ffffffff817db150>] ? gs_change+0xb/0xb
-
-Line 2776 of block/cfq-iosched.c in v3.0-rc5 is as follows:
-
-        if (rcu_dereference(ioc->ioc_data) == cic) {
-
-This form says that it must be in a plain vanilla RCU read-side critical
-section, but the "other info" list above shows that this is not the
-case.  Instead, we hold three locks, one of which might be RCU related.
-And maybe that lock really does protect this reference.  If so, the fix
-is to inform RCU, perhaps by changing __cfq_exit_single_io_context() to
-take the struct request_queue "q" from cfq_exit_queue() as an argument,
-which would permit us to invoke rcu_dereference_protected as follows:
-
-        if (rcu_dereference_protected(ioc->ioc_data,
-                                      lockdep_is_held(&q->queue_lock)) == cic) {
-
-With this change, there would be no lockdep-RCU splat emitted if this
-code was invoked either from within an RCU read-side critical section
-or with the ->queue_lock held.  In particular, this would have suppressed
-the above lockdep-RCU splat because ->queue_lock is held (see #2 in the
-list above).
-
-On the other hand, perhaps we really do need an RCU read-side critical
-section.  In this case, the critical section must span the use of the
-return value from rcu_dereference(), or at least until there is some
-reference count incremented or some such.  One way to handle this is to
-add rcu_read_lock() and rcu_read_unlock() as follows:
-
-        rcu_read_lock();
-        if (rcu_dereference(ioc->ioc_data) == cic) {
-                spin_lock(&ioc->lock);
-                rcu_assign_pointer(ioc->ioc_data, NULL);
-                spin_unlock(&ioc->lock);
-        }
-        rcu_read_unlock();
-
-With this change, the rcu_dereference() is always within an RCU
-read-side critical section, which again would have suppressed the
-above lockdep-RCU splat.
-
-But in this particular case, we don't actually deference the pointer
-returned from rcu_dereference().  Instead, that pointer is just compared
-to the cic pointer, which means that the rcu_dereference() can be replaced
-by rcu_access_pointer() as follows:
-
-        if (rcu_access_pointer(ioc->ioc_data) == cic) {
-
-Because it is legal to invoke rcu_access_pointer() without protection,
-this change would also suppress the above lockdep-RCU splat.
diff --git a/Documentation/RCU/lockdep.txt b/Documentation/RCU/lockdep.txt
index a102d4b3724..d7a49b2f699 100644
--- a/Documentation/RCU/lockdep.txt
+++ b/Documentation/RCU/lockdep.txt
@@ -32,27 +32,9 @@ checking of rcu_dereference() primitives:
         srcu_dereference(p, sp):
                 Check for SRCU read-side critical section.
         rcu_dereference_check(p, c):
-                Use explicit check expression "c" along with
-                rcu_read_lock_held().  This is useful in code that is
-                invoked by both RCU readers and updaters.
-        rcu_dereference_bh_check(p, c):
-                Use explicit check expression "c" along with
-                rcu_read_lock_bh_held().  This is useful in code that
-                is invoked by both RCU-bh readers and updaters.
-        rcu_dereference_sched_check(p, c):
-                Use explicit check expression "c" along with
-                rcu_read_lock_sched_held().  This is useful in code that
-                is invoked by both RCU-sched readers and updaters.
-        srcu_dereference_check(p, c):
-                Use explicit check expression "c" along with
-                srcu_read_lock_held()().  This is useful in code that
-                is invoked by both SRCU readers and updaters.
-        rcu_dereference_index_check(p, c):
-                Use explicit check expression "c", but the caller
-                must supply one of the rcu_read_lock_held() functions.
-                This is useful in code that uses RCU-protected arrays
-                that is invoked by both RCU readers and updaters.
-        rcu_dereference_raw(p):
+                Use explicit check expression "c".  This is useful in
+                code that is invoked by both readers and updaters.
+        rcu_dereference_raw(p)
                 Don't check.  (Use sparingly, if at all.)
         rcu_dereference_protected(p, c):
                 Use explicit check expression "c", and omit all barriers
@@ -66,11 +48,13 @@ checking of rcu_dereference() primitives:
                 value of the pointer itself, for example, against NULL.
 
 The rcu_dereference_check() check expression can be any boolean
-expression, but would normally include a lockdep expression.  However,
-any boolean expression can be used.  For a moderately ornate example,
-consider the following:
+expression, but would normally include one of the rcu_read_lock_held()
+family of functions and a lockdep expression.  However, any boolean
+expression can be used.  For a moderately ornate example, consider
+the following:
 
         file = rcu_dereference_check(fdt->fd[fd],
+                                     rcu_read_lock_held() ||
                                      lockdep_is_held(&files->file_lock) ||
                                      atomic_read(&files->count) == 1);
 
@@ -78,7 +62,7 @@ This expression picks up the pointer "fdt->fd[fd]" in an RCU-safe manner,
 and, if CONFIG_PROVE_RCU is configured, verifies that this expression
 is used in:
 
-1.      An RCU read-side critical section (implicit), or
+1.      An RCU read-side critical section, or
 2.      with files->file_lock held, or
 3.      on an unshared files_struct.
 
diff --git a/Documentation/RCU/rcu.txt b/Documentation/RCU/rcu.txt
index bf778332a28..31852705b58 100644
--- a/Documentation/RCU/rcu.txt
+++ b/Documentation/RCU/rcu.txt
@@ -38,11 +38,11 @@ o	How can the updater tell when a grace period has completed
 
         Preemptible variants of RCU (CONFIG_TREE_PREEMPT_RCU) get the
         same effect, but require that the readers manipulate CPU-local
-        counters.  These counters allow limited types of blocking within
-        RCU read-side critical sections.  SRCU also uses CPU-local
-        counters, and permits general blocking within RCU read-side
-        critical sections.  These variants of RCU detect grace periods
-        by sampling these counters.
+        counters.  These counters allow limited types of blocking
+        within RCU read-side critical sections.  SRCU also uses
+        CPU-local counters, and permits general blocking within
+        RCU read-side critical sections.  These two variants of
+        RCU detect grace periods by sampling these counters.
 
 o       If I am running on a uniprocessor kernel, which can only do one
         thing at a time, why should I wait for a grace period?
diff --git a/Documentation/RCU/rcubarrier.txt b/Documentation/RCU/rcubarrier.txt
index 38428c12513..e439a0edee2 100644
--- a/Documentation/RCU/rcubarrier.txt
+++ b/Documentation/RCU/rcubarrier.txt
@@ -79,6 +79,8 @@ complete. Pseudo-code using rcu_barrier() is as follows:
    2. Execute rcu_barrier().
    3. Allow the module to be unloaded.
 
+Quick Quiz #1: Why is there no srcu_barrier()?
+
 The rcutorture module makes use of rcu_barrier in its exit function
 as follows:
 
@@ -160,7 +162,7 @@ for any pre-existing callbacks to complete.
 Then lines 55-62 print status and do operation-specific cleanup, and
 then return, permitting the module-unload operation to be completed.
 
-Quick Quiz #1: Is there any other situation where rcu_barrier() might
+Quick Quiz #2: Is there any other situation where rcu_barrier() might
         be required?
 
 Your module might have additional complications. For example, if your
@@ -240,7 +242,7 @@ reaches zero, as follows:
  4 complete(&rcu_barrier_completion);
  5 }
 
-Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes
+Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes
         immediately (thus incrementing rcu_barrier_cpu_count to the
         value one), but the other CPU's rcu_barrier_func() invocations
         are delayed for a full grace period? Couldn't this result in
@@ -257,7 +259,12 @@ so that your module may be safely unloaded.
 
 Answers to Quick Quizzes
 
-Quick Quiz #1: Is there any other situation where rcu_barrier() might
+Quick Quiz #1: Why is there no srcu_barrier()?
+
+Answer: Since there is no call_srcu(), there can be no outstanding SRCU
+        callbacks. Therefore, there is no need to wait for them.
+
+Quick Quiz #2: Is there any other situation where rcu_barrier() might
         be required?
 
 Answer: Interestingly enough, rcu_barrier() was not originally
@@ -271,7 +278,7 @@ Answer: Interestingly enough, rcu_barrier() was not originally
         implementing rcutorture, and found that rcu_barrier() solves
         this problem as well.
 
-Quick Quiz #2: What happens if CPU 0's rcu_barrier_func() executes
+Quick Quiz #3: What happens if CPU 0's rcu_barrier_func() executes
         immediately (thus incrementing rcu_barrier_cpu_count to the
         value one), but the other CPU's rcu_barrier_func() invocations
         are delayed for a full grace period? Couldn't this result in
diff --git a/Documentation/RCU/rcuref.txt b/Documentation/RCU/rcuref.txt
index 141d531aa14..4202ad09313 100644
--- a/Documentation/RCU/rcuref.txt
+++ b/Documentation/RCU/rcuref.txt
@@ -20,7 +20,7 @@ release_referenced()			delete()
 {                                       {
     ...                                     write_lock(&list_lock);
     atomic_dec(&el->rc, relfunc)            ...
-    ...                                     remove_element
+    ...                                     delete_element
 }                                           write_unlock(&list_lock);
                                             ...
                                             if (atomic_dec_and_test(&el->rc))
@@ -52,7 +52,7 @@ release_referenced()			delete()
 {                                       {
     ...                                     spin_lock(&list_lock);
     if (atomic_dec_and_test(&el->rc))       ...
-        call_rcu(&el->head, el_free);       remove_element
+        call_rcu(&el->head, el_free);       delete_element
     ...                                     spin_unlock(&list_lock);
 }                                           ...
                                             if (atomic_dec_and_test(&el->rc))
@@ -64,60 +64,3 @@ Sometimes, a reference to the element needs to be obtained in the
 update (write) stream.  In such cases, atomic_inc_not_zero() might be
 overkill, since we hold the update-side spinlock.  One might instead
 use atomic_inc() in such cases.
-
-It is not always convenient to deal with "FAIL" in the
-search_and_reference() code path.  In such cases, the
-atomic_dec_and_test() may be moved from delete() to el_free()
-as follows:
-
-1.                                      2.
-add()                                   search_and_reference()
-{                                       {
-    alloc_object                            rcu_read_lock();
-    ...                                     search_for_element
-    atomic_set(&el->rc, 1);                 atomic_inc(&el->rc);
-    spin_lock(&list_lock);                  ...
-
-    add_element                             rcu_read_unlock();
-    ...                                 }
-    spin_unlock(&list_lock);            4.
-}                                       delete()
-3.                                      {
-release_referenced()                        spin_lock(&list_lock);
-{                                           ...
-    ...                                     remove_element
-    if (atomic_dec_and_test(&el->rc))       spin_unlock(&list_lock);
-        kfree(el);                          ...
-    ...                                     call_rcu(&el->head, el_free);
-}                                           ...
-5.                                      }
-void el_free(struct rcu_head *rhp)
-{
-    release_referenced();
-}
-
-The key point is that the initial reference added by add() is not removed
-until after a grace period has elapsed following removal.  This means that
-search_and_reference() cannot find this element, which means that the value
-of el->rc cannot increase.  Thus, once it reaches zero, there are no
-readers that can or ever will be able to reference the element.  The
-element can therefore safely be freed.  This in turn guarantees that if
-any reader finds the element, that reader may safely acquire a reference
-without checking the value of the reference counter.
-
-In cases where delete() can sleep, synchronize_rcu() can be called from
-delete(), so that el_free() can be subsumed into delete as follows:
-
-4.
-delete()
-{
-    spin_lock(&list_lock);
-    ...
-    remove_element
-    spin_unlock(&list_lock);
-    ...
-    synchronize_rcu();
-    if (atomic_dec_and_test(&el->rc))
-        kfree(el);
-    ...
-}
diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt
index 1927151b386..4e959208f73 100644
--- a/Documentation/RCU/stallwarn.txt
+++ b/Documentation/RCU/stallwarn.txt
@@ -12,38 +12,14 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
         This kernel configuration parameter defines the period of time
         that RCU will wait from the beginning of a grace period until it
         issues an RCU CPU stall warning.  This time period is normally
-        sixty seconds.
+        ten seconds.
 
-        This configuration parameter may be changed at runtime via the
-        /sys/module/rcutree/parameters/rcu_cpu_stall_timeout, however
-        this parameter is checked only at the beginning of a cycle.
-        So if you are 30 seconds into a 70-second stall, setting this
-        sysfs parameter to (say) five will shorten the timeout for the
-        -next- stall, or the following warning for the current stall
-        (assuming the stall lasts long enough).  It will not affect the
-        timing of the next warning for the current stall.
+RCU_SECONDS_TILL_STALL_RECHECK
 
-        Stall-warning messages may be enabled and disabled completely via
-        /sys/module/rcutree/parameters/rcu_cpu_stall_suppress.
-
-CONFIG_RCU_CPU_STALL_VERBOSE
-
-        This kernel configuration parameter causes the stall warning to
-        also dump the stacks of any tasks that are blocking the current
-        RCU-preempt grace period.
-
-RCU_CPU_STALL_INFO
-
-        This kernel configuration parameter causes the stall warning to
-        print out additional per-CPU diagnostic information, including
-        information on scheduling-clock ticks and RCU's idle-CPU tracking.
-
-RCU_STALL_DELAY_DELTA
-
-        Although the lockdep facility is extremely useful, it does add
-        some overhead.  Therefore, under CONFIG_PROVE_RCU, the
-        RCU_STALL_DELAY_DELTA macro allows five extra seconds before
-        giving an RCU CPU stall warning message.
+        This macro defines the period of time that RCU will wait after
+        issuing a stall warning until it issues another stall warning
+        for the same stall.  This time period is normally set to three
+        times the check interval plus thirty seconds.
 
 RCU_STALL_RAT_DELAY
 
@@ -88,54 +64,6 @@ INFO: rcu_bh_state detected stalls on CPUs/tasks: { } (detected by 4, 2502 jiffi
 
 This is rare, but does happen from time to time in real life.
 
-If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,
-more information is printed with the stall-warning message, for example:
-
-        INFO: rcu_preempt detected stall on CPU
-        0: (63959 ticks this GP) idle=241/3fffffffffffffff/0
-           (t=65000 jiffies)
-
-In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
-printed:
-
-        INFO: rcu_preempt detected stall on CPU
-        0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 drain=0 . timer not pending
-           (t=65000 jiffies)
-
-The "(64628 ticks this GP)" indicates that this CPU has taken more
-than 64,000 scheduling-clock interrupts during the current stalled
-grace period.  If the CPU was not yet aware of the current grace
-period (for example, if it was offline), then this part of the message
-indicates how many grace periods behind the CPU is.
-
-The "idle=" portion of the message prints the dyntick-idle state.
-The hex number before the first "/" is the low-order 12 bits of the
-dynticks counter, which will have an even-numbered value if the CPU is
-in dyntick-idle mode and an odd-numbered value otherwise.  The hex
-number between the two "/"s is the value of the nesting, which will
-be a small positive number if in the idle loop and a very large positive
-number (as shown above) otherwise.
-
-For CONFIG_RCU_FAST_NO_HZ kernels, the "drain=0" indicates that the CPU is
-not in the process of trying to force itself into dyntick-idle state, the
-"." indicates that the CPU has not given up forcing RCU into dyntick-idle
-mode (it would be "H" otherwise), and the "timer not pending" indicates
-that the CPU has not recently forced RCU into dyntick-idle mode (it
-would otherwise indicate the number of microseconds remaining in this
-forced state).
-
-
-Multiple Warnings From One Stall
-
-If a stall lasts long enough, multiple stall-warning messages will be
-printed for it.  The second and subsequent messages are printed at
-longer intervals, so that the time between (say) the first and second
-message will be about three times the interval between the beginning
-of the stall and the first message.
-
-
-What Causes RCU CPU Stall Warnings?
-
 So your kernel printed an RCU CPU stall warning.  The next question is
 "What caused it?"  The following problems can result in RCU CPU stall
 warnings:
@@ -173,11 +101,6 @@ o	A CPU-bound real-time task in a CONFIG_PREEMPT_RT kernel that
         CONFIG_TREE_PREEMPT_RCU case, you might see stall-warning
         messages.
 
-o       A hardware or software issue shuts off the scheduler-clock
-        interrupt on a CPU that is not in dyntick-idle mode.  This
-        problem really has happened, and seems to be most likely to
-        result in RCU CPU stall warnings for CONFIG_NO_HZ=n kernels.
-
 o       A bug in the RCU implementation.
 
 o       A hardware failure.  This is quite unlikely, but has occurred
@@ -186,11 +109,12 @@ o	A hardware failure.  This is quite unlikely, but has occurred
         This resulted in a series of RCU CPU stall warnings, eventually
         leading the realization that the CPU had failed.
 
-The RCU, RCU-sched, and RCU-bh implementations have CPU stall warning.
-SRCU does not have its own CPU stall warnings, but its calls to
-synchronize_sched() will result in RCU-sched detecting RCU-sched-related
-CPU stalls.  Please note that RCU only detects CPU stalls when there is
-a grace period in progress.  No grace period, no CPU stall warnings.
+The RCU, RCU-sched, and RCU-bh implementations have CPU stall
+warning.  SRCU does not have its own CPU stall warnings, but its
+calls to synchronize_sched() will result in RCU-sched detecting
+RCU-sched-related CPU stalls.  Please note that RCU only detects
+CPU stalls when there is a grace period in progress.  No grace period,
+no CPU stall warnings.
 
 To diagnose the cause of the stall, inspect the stack traces.
 The offending function will usually be near the top of the stack.
@@ -200,5 +124,4 @@ is occurring, which will usually be in the function nearest the top of
 that portion of the stack which remains the same from trace to trace.
 If you can reliably trigger the stall, ftrace can be quite helpful.
 
-RCU bugs can often be debugged with the help of CONFIG_RCU_TRACE
-and with RCU's event tracing.
+RCU bugs can often be debugged with the help of CONFIG_RCU_TRACE.
diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt
index 7dce8a17eac..5d9016795fd 100644
--- a/Documentation/RCU/torture.txt
+++ b/Documentation/RCU/torture.txt
@@ -42,21 +42,11 @@ fqs_holdoff	Holdoff time (in microseconds) between consecutive calls
 fqs_stutter     Wait time (in seconds) between consecutive bursts
                 of calls to force_quiescent_state().
 
-irqreader       Says to invoke RCU readers from irq level.  This is currently
+irqreaders      Says to invoke RCU readers from irq level.  This is currently
                 done via timers.  Defaults to "1" for variants of RCU that
                 permit this.  (Or, more accurately, variants of RCU that do
                 -not- permit this know to ignore this variable.)
 
-n_barrier_cbs   If this is nonzero, RCU barrier testing will be conducted,
-                in which case n_barrier_cbs specifies the number of
-                RCU callbacks (and corresponding kthreads) to use for
-                this testing.  The value cannot be negative.  If you
-                specify this to be non-zero when torture_type indicates a
-                synchronous RCU implementation (one for which a member of
-                the synchronize_rcu() rather than the call_rcu() family is
-                used -- see the documentation for torture_type below), an
-                error will be reported and no testing will be carried out.
-
 nfakewriters    This is the number of RCU fake writer threads to run.  Fake
                 writer threads repeatedly use the synchronous "wait for
                 current readers" function of the interface selected by
@@ -71,49 +61,11 @@ nreaders	This is the number of RCU reading threads supported.
                 To properly exercise RCU implementations with preemptible
                 read-side critical sections.
 
-onoff_interval
-                The number of seconds between each attempt to execute a
-                randomly selected CPU-hotplug operation.  Defaults to
-                zero, which disables CPU hotplugging.  In HOTPLUG_CPU=n
-                kernels, rcutorture will silently refuse to do any
-                CPU-hotplug operations regardless of what value is
-                specified for onoff_interval.
-
-onoff_holdoff   The number of seconds to wait until starting CPU-hotplug
-                operations.  This would normally only be used when
-                rcutorture was built into the kernel and started
-                automatically at boot time, in which case it is useful
-                in order to avoid confusing boot-time code with CPUs
-                coming and going.
-
 shuffle_interval
                 The number of seconds to keep the test threads affinitied
                 to a particular subset of the CPUs, defaults to 3 seconds.
                 Used in conjunction with test_no_idle_hz.
 
-shutdown_secs   The number of seconds to run the test before terminating
-                the test and powering off the system.  The default is
-                zero, which disables test termination and system shutdown.
-                This capability is useful for automated testing.
-
-stall_cpu       The number of seconds that a CPU should be stalled while
-                within both an rcu_read_lock() and a preempt_disable().
-                This stall happens only once per rcutorture run.
-                If you need multiple stalls, use modprobe and rmmod to
-                repeatedly run rcutorture.  The default for stall_cpu
-                is zero, which prevents rcutorture from stalling a CPU.
-
-                Note that attempts to rmmod rcutorture while the stall
-                is ongoing will hang, so be careful what value you
-                choose for this module parameter!  In addition, too-large
-                values for stall_cpu might well induce failures and
-                warnings in other parts of the kernel.  You have been
-                warned!
-
-stall_cpu_holdoff
-                The number of seconds to wait after rcutorture starts
-                before stalling a CPU.  Defaults to 10 seconds.
-
 stat_interval   The number of seconds between output of torture
                 statistics (via printk()).  Regardless of the interval,
                 statistics are printed when the module is unloaded.
@@ -127,77 +79,19 @@ stutter		The length of time to run the test before pausing for this
                 Specifying "stutter=0" causes the test to run continuously
                 without pausing, which is the old default behavior.
 
-test_boost      Whether or not to test the ability of RCU to do priority
-                boosting.  Defaults to "test_boost=1", which performs
-                RCU priority-inversion testing only if the selected
-                RCU implementation supports priority boosting.  Specifying
-                "test_boost=0" never performs RCU priority-inversion
-                testing.  Specifying "test_boost=2" performs RCU
-                priority-inversion testing even if the selected RCU
-                implementation does not support RCU priority boosting,
-                which can be used to test rcutorture's ability to
-                carry out RCU priority-inversion testing.
-
-test_boost_interval
-                The number of seconds in an RCU priority-inversion test
-                cycle.  Defaults to "test_boost_interval=7".  It is
-                usually wise for this value to be relatively prime to
-                the value selected for "stutter".
-
-test_boost_duration
-                The number of seconds to do RCU priority-inversion testing
-                within any given "test_boost_interval".  Defaults to
-                "test_boost_duration=4".
-
 test_no_idle_hz Whether or not to test the ability of RCU to operate in
                 a kernel that disables the scheduling-clock interrupt to
                 idle CPUs.  Boolean parameter, "1" to test, "0" otherwise.
                 Defaults to omitting this test.
 
-torture_type    The type of RCU to test, with string values as follows:
-
-                "rcu":  rcu_read_lock(), rcu_read_unlock() and call_rcu().
-
-                "rcu_sync":  rcu_read_lock(), rcu_read_unlock(), and
-                        synchronize_rcu().
-
-                "rcu_expedited": rcu_read_lock(), rcu_read_unlock(), and
-                        synchronize_rcu_expedited().
-
-                "rcu_bh": rcu_read_lock_bh(), rcu_read_unlock_bh(), and
-                        call_rcu_bh().
-
-                "rcu_bh_sync": rcu_read_lock_bh(), rcu_read_unlock_bh(),
-                        and synchronize_rcu_bh().
-
-                "rcu_bh_expedited": rcu_read_lock_bh(), rcu_read_unlock_bh(),
-                        and synchronize_rcu_bh_expedited().
-
-                "srcu": srcu_read_lock(), srcu_read_unlock() and
-                        call_srcu().
-
-                "srcu_sync": srcu_read_lock(), srcu_read_unlock() and
-                        synchronize_srcu().
-
-                "srcu_expedited": srcu_read_lock(), srcu_read_unlock() and
-                        synchronize_srcu_expedited().
-
-                "srcu_raw": srcu_read_lock_raw(), srcu_read_unlock_raw(),
-                        and call_srcu().
-
-                "srcu_raw_sync": srcu_read_lock_raw(), srcu_read_unlock_raw(),
-                        and synchronize_srcu().
-
-                "sched": preempt_disable(), preempt_enable(), and
-                        call_rcu_sched().
-
-                "sched_sync": preempt_disable(), preempt_enable(), and
-                        synchronize_sched().
-
-                "sched_expedited": preempt_disable(), preempt_enable(), and
-                        synchronize_sched_expedited().
-
-                Defaults to "rcu".
+torture_type    The type of RCU to test: "rcu" for the rcu_read_lock() API,
+                "rcu_sync" for rcu_read_lock() with synchronous reclamation,
+                "rcu_bh" for the rcu_read_lock_bh() API, "rcu_bh_sync" for
+                rcu_read_lock_bh() with synchronous reclamation, "srcu" for
+                the "srcu_read_lock()" API, "sched" for the use of
+                preempt_disable() together with synchronize_sched(),
+                and "sched_expedited" for the use of preempt_disable()
+                with synchronize_sched_expedited().
 
 verbose         Enable debug printk()s.  Default is disabled.
 
@@ -206,12 +100,12 @@ OUTPUT
 
 The statistics output is as follows:
 
-        rcu-torture:--- Start of test: nreaders=16 nfakewriters=4 stat_interval=30 verbose=0 test_no_idle_hz=1 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4
-        rcu-torture: rtc:           (null) ver: 155441 tfle: 0 rta: 155441 rtaf: 8884 rtf: 155440 rtmbe: 0 rtbe: 0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 3055767
-        rcu-torture: Reader Pipe:  727860534 34213 0 0 0 0 0 0 0 0 0
-        rcu-torture: Reader Batch:  727877838 17003 0 0 0 0 0 0 0 0 0
-        rcu-torture: Free-Block Circulation:  155440 155440 155440 155440 155440 155440 155440 155440 155440 155440 0
-        rcu-torture:--- End of test: SUCCESS: nreaders=16 nfakewriters=4 stat_interval=30 verbose=0 test_no_idle_hz=1 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0 fqs_holdoff=0 fqs_stutter=3 test_boost=1/0 test_boost_interval=7 test_boost_duration=4
+        rcu-torture: --- Start of test: nreaders=16 stat_interval=0 verbose=0
+        rcu-torture: rtc: 0000000000000000 ver: 1916 tfle: 0 rta: 1916 rtaf: 0 rtf: 1915
+        rcu-torture: Reader Pipe:  1466408 9747 0 0 0 0 0 0 0 0 0
+        rcu-torture: Reader Batch:  1464477 11678 0 0 0 0 0 0 0 0
+        rcu-torture: Free-Block Circulation:  1915 1915 1915 1915 1915 1915 1915 1915 1915 1915 0
+        rcu-torture: --- End of test
 
 The command "dmesg | grep torture:" will extract this information on
 most systems.  On more esoteric configurations, it may be necessary to
@@ -219,58 +113,26 @@ use other commands to access the output of the printk()s used by
 the RCU torture test.  The printk()s use KERN_ALERT, so they should
 be evident.  ;-)
 
-The first and last lines show the rcutorture module parameters, and the
-last line shows either "SUCCESS" or "FAILURE", based on rcutorture's
-automatic determination as to whether RCU operated correctly.
-
 The entries are as follows:
 
 o       "rtc": The hexadecimal address of the structure currently visible
         to readers.
 
-o       "ver": The number of times since boot that the RCU writer task
+o       "ver": The number of times since boot that the rcutw writer task
         has changed the structure visible to readers.
 
 o       "tfle": If non-zero, indicates that the "torture freelist"
-        containing structures to be placed into the "rtc" area is empty.
+        containing structure to be placed into the "rtc" area is empty.
         This condition is important, since it can fool you into thinking
         that RCU is working when it is not.  :-/
 
 o       "rta": Number of structures allocated from the torture freelist.
 
 o       "rtaf": Number of allocations from the torture freelist that have
-        failed due to the list being empty.  It is not unusual for this
-        to be non-zero, but it is bad for it to be a large fraction of
-        the value indicated by "rta".
+        failed due to the list being empty.
 
 o       "rtf": Number of frees into the torture freelist.
 
-o       "rtmbe": A non-zero value indicates that rcutorture believes that
-        rcu_assign_pointer() and rcu_dereference() are not working
-        correctly.  This value should be zero.
-
-o       "rtbe": A non-zero value indicates that one of the rcu_barrier()
-        family of functions is not working correctly.
-
-o       "rtbke": rcutorture was unable to create the real-time kthreads
-        used to force RCU priority inversion.  This value should be zero.
-
-o       "rtbre": Although rcutorture successfully created the kthreads
-        used to force RCU priority inversion, it was unable to set them
-        to the real-time priority level of 1.  This value should be zero.
-
-o       "rtbf": The number of times that RCU priority boosting failed
-        to resolve RCU priority inversion.
-
-o       "rtb": The number of times that rcutorture attempted to force
-        an RCU priority inversion condition.  If you are testing RCU
-        priority boosting via the "test_boost" module parameter, this
-        value should be non-zero.
-
-o       "nt": The number of times rcutorture ran RCU read-side code from
-        within a timer handler.  This value should be non-zero only
-        if you specified the "irqreader" module parameter.
-
 o       "Reader Pipe": Histogram of "ages" of structures seen by readers.
         If any entries past the first two are non-zero, RCU is broken.
         And rcutorture prints the error flag string "!!!" to make sure
@@ -300,15 +162,26 @@ o	"Free-Block Circulation": Shows the number of torture structures
         somehow gets incremented farther than it should.
 
 Different implementations of RCU can provide implementation-specific
-additional information.  For example, SRCU provides the following
-additional line:
+additional information.  For example, SRCU provides the following:
 
+        srcu-torture: rtc: f8cf46a8 ver: 355 tfle: 0 rta: 356 rtaf: 0 rtf: 346 rtmbe: 0
+        srcu-torture: Reader Pipe:  559738 939 0 0 0 0 0 0 0 0 0
+        srcu-torture: Reader Batch:  560434 243 0 0 0 0 0 0 0 0
+        srcu-torture: Free-Block Circulation:  355 354 353 352 351 350 349 348 347 346 0
         srcu-torture: per-CPU(idx=1): 0(0,1) 1(0,1) 2(0,0) 3(0,1)
 
-This line shows the per-CPU counter state.  The numbers in parentheses are
-the values of the "old" and "current" counters for the corresponding CPU.
-The "idx" value maps the "old" and "current" values to the underlying
-array, and is useful for debugging.
+The first four lines are similar to those for RCU.  The last line shows
+the per-CPU counter state.  The numbers in parentheses are the values
+of the "old" and "current" counters for the corresponding CPU.  The
+"idx" value maps the "old" and "current" values to the underlying array,
+and is useful for debugging.
+
+Similarly, sched_expedited RCU provides the following:
+
+        sched_expedited-torture: rtc: d0000000016c1880 ver: 1090796 tfle: 0 rta: 1090796 rtaf: 0 rtf: 1090787 rtmbe: 0 nt: 27713319
+        sched_expedited-torture: Reader Pipe:  12660320201 95875 0 0 0 0 0 0 0 0 0
+        sched_expedited-torture: Reader Batch:  12660424885 0 0 0 0 0 0 0 0 0 0
+        sched_expedited-torture: Free-Block Circulation:  1090795 1090795 1090794 1090793 1090792 1090791 1090790 1090789 1090788 1090787 0
 
 
 USAGE
@@ -318,13 +191,11 @@ The following script may be used to torture RCU:
         #!/bin/sh
 
         modprobe rcutorture
-        sleep 3600
+        sleep 100
         rmmod rcutorture
         dmesg | grep torture:
 
 The output can be manually inspected for the error flag of "!!!".
 One could of course create a more elaborate script that automatically
-checked for such errors.  The "rmmod" command forces a "SUCCESS",
-"FAILURE", or "RCU_HOTPLUG" indication to be printk()ed.  The first
-two are self-explanatory, while the last indicates that while there
-were no RCU failures, CPU-hotplug problems were detected.
+checked for such errors.  The "rmmod" command forces a "SUCCESS" or
+"FAILURE" indication to be printk()ed.
diff --git a/Documentation/RCU/trace.txt b/Documentation/RCU/trace.txt
index c776968f446..8173cec473a 100644
--- a/Documentation/RCU/trace.txt
+++ b/Documentation/RCU/trace.txt
@@ -10,63 +10,51 @@ for rcutree and next for rcutiny.
 
 CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats
 
-These implementations of RCU provide several debugfs directories under the
+These implementations of RCU provides several debugfs files under the
 top-level directory "rcu":
 
-rcu/rcu_bh
-rcu/rcu_preempt
-rcu/rcu_sched
-
-Each directory contains files for the corresponding flavor of RCU.
-Note that rcu/rcu_preempt is only present for CONFIG_TREE_PREEMPT_RCU.
-For CONFIG_TREE_RCU, the RCU flavor maps onto the RCU-sched flavor,
-so that activity for both appears in rcu/rcu_sched.
-
-In addition, the following file appears in the top-level directory:
-rcu/rcutorture.  This file displays rcutorture test progress.  The output
-of "cat rcu/rcutorture" looks as follows:
-
-rcutorture test sequence: 0 (test in progress)
-rcutorture update version number: 615
-
-The first line shows the number of rcutorture tests that have completed
-since boot.  If a test is currently running, the "(test in progress)"
-string will appear as shown above.  The second line shows the number of
-update cycles that the current test has started, or zero if there is
-no test in progress.
-
-
-Within each flavor directory (rcu/rcu_bh, rcu/rcu_sched, and possibly
-also rcu/rcu_preempt) the following files will be present:
-
-rcudata:
+rcu/rcudata:
         Displays fields in struct rcu_data.
-rcuexp:
-        Displays statistics for expedited grace periods.
-rcugp:
+rcu/rcudata.csv:
+        Comma-separated values spreadsheet version of rcudata.
+rcu/rcugp:
         Displays grace-period counters.
-rcuhier:
+rcu/rcuhier:
         Displays the struct rcu_node hierarchy.
-rcu_pending:
+rcu/rcu_pending:
         Displays counts of the reasons rcu_pending() decided that RCU had
         work to do.
-rcuboost:
+rcu/rcutorture:
+        Displays rcutorture test progress.
+rcu/rcuboost:
         Displays RCU boosting statistics.  Only present if
         CONFIG_RCU_BOOST=y.
 
-The output of "cat rcu/rcu_preempt/rcudata" looks as follows:
-
-  0!c=30455 g=30456 pq=1 qp=1 dt=126535/140000000000000/0 df=2002 of=4 ql=0/0 qs=N... b=10 ci=74572 nci=0 co=1131 ca=716
-  1!c=30719 g=30720 pq=1 qp=0 dt=132007/140000000000000/0 df=1874 of=10 ql=0/0 qs=N... b=10 ci=123209 nci=0 co=685 ca=982
-  2!c=30150 g=30151 pq=1 qp=1 dt=138537/140000000000000/0 df=1707 of=8 ql=0/0 qs=N... b=10 ci=80132 nci=0 co=1328 ca=1458
-  3 c=31249 g=31250 pq=1 qp=0 dt=107255/140000000000000/0 df=1749 of=6 ql=0/450 qs=NRW. b=10 ci=151700 nci=0 co=509 ca=622
-  4!c=29502 g=29503 pq=1 qp=1 dt=83647/140000000000000/0 df=965 of=5 ql=0/0 qs=N... b=10 ci=65643 nci=0 co=1373 ca=1521
-  5 c=31201 g=31202 pq=1 qp=1 dt=70422/0/0 df=535 of=7 ql=0/0 qs=.... b=10 ci=58500 nci=0 co=764 ca=698
-  6!c=30253 g=30254 pq=1 qp=1 dt=95363/140000000000000/0 df=780 of=5 ql=0/0 qs=N... b=10 ci=100607 nci=0 co=1414 ca=1353
-  7 c=31178 g=31178 pq=1 qp=0 dt=91536/0/0 df=547 of=4 ql=0/0 qs=.... b=10 ci=109819 nci=0 co=1115 ca=969
-
-This file has one line per CPU, or eight for this 8-CPU system.
-The fields are as follows:
+The output of "cat rcu/rcudata" looks as follows:
+
+rcu_sched:
+  0 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=545/1/0 df=50 of=0 ri=0 ql=163 qs=NRW. kt=0/W/0 ktl=ebc3 b=10 ci=153737 co=0 ca=0
+  1 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=967/1/0 df=58 of=0 ri=0 ql=634 qs=NRW. kt=0/W/1 ktl=58c b=10 ci=191037 co=0 ca=0
+  2 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=1081/1/0 df=175 of=0 ri=0 ql=74 qs=N.W. kt=0/W/2 ktl=da94 b=10 ci=75991 co=0 ca=0
+  3 c=20942 g=20943 pq=1 pqc=20942 qp=1 dt=1846/0/0 df=404 of=0 ri=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=72261 co=0 ca=0
+  4 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=369/1/0 df=83 of=0 ri=0 ql=48 qs=N.W. kt=0/W/4 ktl=e0e7 b=10 ci=128365 co=0 ca=0
+  5 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=381/1/0 df=64 of=0 ri=0 ql=169 qs=NRW. kt=0/W/5 ktl=fb2f b=10 ci=164360 co=0 ca=0
+  6 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=1037/1/0 df=183 of=0 ri=0 ql=62 qs=N.W. kt=0/W/6 ktl=d2ad b=10 ci=65663 co=0 ca=0
+  7 c=20897 g=20897 pq=1 pqc=20896 qp=0 dt=1572/0/0 df=382 of=0 ri=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=75006 co=0 ca=0
+rcu_bh:
+  0 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=545/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/0 ktl=ebc3 b=10 ci=0 co=0 ca=0
+  1 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=967/1/0 df=3 of=0 ri=1 ql=0 qs=.... kt=0/W/1 ktl=58c b=10 ci=151 co=0 ca=0
+  2 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1081/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/2 ktl=da94 b=10 ci=0 co=0 ca=0
+  3 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1846/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=0 co=0 ca=0
+  4 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=369/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/4 ktl=e0e7 b=10 ci=0 co=0 ca=0
+  5 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=381/1/0 df=4 of=0 ri=1 ql=0 qs=.... kt=0/W/5 ktl=fb2f b=10 ci=0 co=0 ca=0
+  6 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1037/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/6 ktl=d2ad b=10 ci=0 co=0 ca=0
+  7 c=1474 g=1474 pq=1 pqc=1473 qp=0 dt=1572/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=0 co=0 ca=0
+
+The first section lists the rcu_data structures for rcu_sched, the second
+for rcu_bh.  Note that CONFIG_TREE_PREEMPT_RCU kernels will have an
+additional section for rcu_preempt.  Each section has one line per CPU,
+or eight for this 8-CPU system.  The fields are as follows:
 
 o       The number at the beginning of each line is the CPU number.
         CPUs numbers followed by an exclamation mark are offline,
@@ -76,13 +64,11 @@ o	The number at the beginning of each line is the CPU number.
         substantially larger than the number of actual CPUs.
 
 o       "c" is the count of grace periods that this CPU believes have
-        completed.  Offlined CPUs and CPUs in dynticks idle mode may lag
-        quite a ways behind, for example, CPU 4 under "rcu_sched" above,
-        which has been offline through 16 RCU grace periods.  It is not
-        unusual to see offline CPUs lagging by thousands of grace periods.
-        Note that although the grace-period number is an unsigned long,
-        it is printed out as a signed long to allow more human-friendly
-        representation near boot time.
+        completed.  Offlined CPUs and CPUs in dynticks idle mode may
+        lag quite a ways behind, for example, CPU 6 under "rcu_sched"
+        above, which has been offline through not quite 40,000 RCU grace
+        periods.  It is not unusual to see CPUs lagging by thousands of
+        grace periods.
 
 o       "g" is the count of grace periods that this CPU believes have
         started.  Again, offlined CPUs and CPUs in dynticks idle mode
@@ -98,25 +84,34 @@ o	"pq" indicates that this CPU has passed through a quiescent state
         CPU has not yet reported that fact, (2) some other CPU has not
         yet reported for this grace period, or (3) both.
 
+o       "pqc" indicates which grace period the last-observed quiescent
+        state for this CPU corresponds to.  This is important for handling
+        the race between CPU 0 reporting an extended dynticks-idle
+        quiescent state for CPU 1 and CPU 1 suddenly waking up and
+        reporting its own quiescent state.  If CPU 1 was the last CPU
+        for the current grace period, then the CPU that loses this race
+        will attempt to incorrectly mark CPU 1 as having checked in for
+        the next grace period!
+
 o       "qp" indicates that RCU still expects a quiescent state from
         this CPU.  Offlined CPUs and CPUs in dyntick idle mode might
         well have qp=1, which is OK: RCU is still ignoring them.
 
 o       "dt" is the current value of the dyntick counter that is incremented
-        when entering or leaving idle, either due to a context switch or
-        due to an interrupt.  This number is even if the CPU is in idle
-        from RCU's viewpoint and odd otherwise.  The number after the
-        first "/" is the interrupt nesting depth when in idle state,
-        or a large number added to the interrupt-nesting depth when
-        running a non-idle task.  Some architectures do not accurately
-        count interrupt nesting when running in non-idle kernel context,
-        which can result in interesting anomalies such as negative
-        interrupt-nesting levels.  The number after the second "/"
-        is the NMI nesting depth.
+        when entering or leaving dynticks idle state, either by the
+        scheduler or by irq.  This number is even if the CPU is in
+        dyntick idle mode and odd otherwise.  The number after the first
+        "/" is the interrupt nesting depth when in dyntick-idle state,
+        or one greater than the interrupt-nesting depth otherwise.
+        The number after the second "/" is the NMI nesting depth.
+
+        This field is displayed only for CONFIG_NO_HZ kernels.
 
 o       "df" is the number of times that some other CPU has forced a
         quiescent state on behalf of this CPU due to this CPU being in
-        idle state.
+        dynticks-idle state.
+
+        This field is displayed only for CONFIG_NO_HZ kernels.
 
 o       "of" is the number of times that some other CPU has forced a
         quiescent state on behalf of this CPU due to this CPU being
@@ -128,14 +123,14 @@ o	"of" is the number of times that some other CPU has forced a
         CPU is offline when it is really alive and kicking) is a fatal
         error, so it makes sense to err conservatively.
 
+o       "ri" is the number of times that RCU has seen fit to send a
+        reschedule IPI to this CPU in order to get it to report a
+        quiescent state.
+
 o       "ql" is the number of RCU callbacks currently residing on
-        this CPU.  The first number is the number of "lazy" callbacks
-        that are known to RCU to only be freeing memory, and the number
-        after the "/" is the total number of callbacks, lazy or not.
-        These counters count callbacks regardless of what phase of
-        grace-period processing that they are in (new, waiting for
-        grace period to start, waiting for grace period to end, ready
-        to invoke).
+        this CPU.  This is the total number of callbacks, regardless
+        of what state they are in (new, waiting for grace period to
+        start, waiting for grace period to end, ready to invoke).
 
 o       "qs" gives an indication of the state of the callback queue
         with four characters:
@@ -163,43 +158,6 @@ o	"qs" gives an indication of the state of the callback queue
         If there are no callbacks in a given one of the above states,
         the corresponding character is replaced by ".".
 
-o       "b" is the batch limit for this CPU.  If more than this number
-        of RCU callbacks is ready to invoke, then the remainder will
-        be deferred.
-
-o       "ci" is the number of RCU callbacks that have been invoked for
-        this CPU.  Note that ci+nci+ql is the number of callbacks that have
-        been registered in absence of CPU-hotplug activity.
-
-o       "nci" is the number of RCU callbacks that have been offloaded from
-        this CPU.  This will always be zero unless the kernel was built
-        with CONFIG_RCU_NOCB_CPU=y and the "rcu_nocbs=" kernel boot
-        parameter was specified.
-
-o       "co" is the number of RCU callbacks that have been orphaned due to
-        this CPU going offline.  These orphaned callbacks have been moved
-        to an arbitrarily chosen online CPU.
-
-o       "ca" is the number of RCU callbacks that have been adopted by this
-        CPU due to other CPUs going offline.  Note that ci+co-ca+ql is
-        the number of RCU callbacks registered on this CPU.
-
-
-Kernels compiled with CONFIG_RCU_BOOST=y display the following from
-/debug/rcu/rcu_preempt/rcudata:
-
-  0!c=12865 g=12866 pq=1 qp=1 dt=83113/140000000000000/0 df=288 of=11 ql=0/0 qs=N... kt=0/O ktl=944 b=10 ci=60709 nci=0 co=748 ca=871
-  1 c=14407 g=14408 pq=1 qp=0 dt=100679/140000000000000/0 df=378 of=7 ql=0/119 qs=NRW. kt=0/W ktl=9b6 b=10 ci=109740 nci=0 co=589 ca=485
-  2 c=14407 g=14408 pq=1 qp=0 dt=105486/0/0 df=90 of=9 ql=0/89 qs=NRW. kt=0/W ktl=c0c b=10 ci=83113 nci=0 co=533 ca=490
-  3 c=14407 g=14408 pq=1 qp=0 dt=107138/0/0 df=142 of=8 ql=0/188 qs=NRW. kt=0/W ktl=b96 b=10 ci=121114 nci=0 co=426 ca=290
-  4 c=14405 g=14406 pq=1 qp=1 dt=50238/0/0 df=706 of=7 ql=0/0 qs=.... kt=0/W ktl=812 b=10 ci=34929 nci=0 co=643 ca=114
-  5!c=14168 g=14169 pq=1 qp=0 dt=45465/140000000000000/0 df=161 of=11 ql=0/0 qs=N... kt=0/O ktl=b4d b=10 ci=47712 nci=0 co=677 ca=722
-  6 c=14404 g=14405 pq=1 qp=0 dt=59454/0/0 df=94 of=6 ql=0/0 qs=.... kt=0/W ktl=e57 b=10 ci=55597 nci=0 co=701 ca=811
-  7 c=14407 g=14408 pq=1 qp=1 dt=68850/0/0 df=31 of=8 ql=0/0 qs=.... kt=0/W ktl=14bd b=10 ci=77475 nci=0 co=508 ca=1042
-
-This is similar to the output discussed above, but contains the following
-additional fields:
-
 o       "kt" is the per-CPU kernel-thread state.  The digit preceding
         the first slash is zero if there is no work pending and 1
         otherwise.  The character between the first pair of slashes is
@@ -226,59 +184,39 @@ o	"kt" is the per-CPU kernel-thread state.  The digit preceding
         The number after the final slash is the CPU that the kthread
         is actually running on.
 
-        This field is displayed only for CONFIG_RCU_BOOST kernels.
-
 o       "ktl" is the low-order 16 bits (in hexadecimal) of the count of
         the number of times that this CPU's per-CPU kthread has gone
         through its loop servicing invoke_rcu_cpu_kthread() requests.
 
-        This field is displayed only for CONFIG_RCU_BOOST kernels.
-
-
-The output of "cat rcu/rcu_preempt/rcuexp" looks as follows:
-
-s=21872 d=21872 w=0 tf=0 wd1=0 wd2=0 n=0 sc=21872 dt=21872 dl=0 dx=21872
-
-These fields are as follows:
-
-o       "s" is the starting sequence number.
-
-o       "d" is the ending sequence number.  When the starting and ending
-        numbers differ, there is an expedited grace period in progress.
-
-o       "w" is the number of times that the sequence numbers have been
-        in danger of wrapping.
-
-o       "tf" is the number of times that contention has resulted in a
-        failure to begin an expedited grace period.
-
-o       "wd1" and "wd2" are the number of times that an attempt to
-        start an expedited grace period found that someone else had
-        completed an expedited grace period that satisfies the
-        attempted request.  "Our work is done."
-
-o       "n" is number of times that contention was so great that
-        the request was demoted from an expedited grace period to
-        a normal grace period.
+o       "b" is the batch limit for this CPU.  If more than this number
+        of RCU callbacks is ready to invoke, then the remainder will
+        be deferred.
 
-o       "sc" is the number of times that the attempt to start a
-        new expedited grace period succeeded.
+o       "ci" is the number of RCU callbacks that have been invoked for
+        this CPU.  Note that ci+ql is the number of callbacks that have
+        been registered in absence of CPU-hotplug activity.
 
-o       "dt" is the number of times that we attempted to update
-        the "d" counter.
+o       "co" is the number of RCU callbacks that have been orphaned due to
+        this CPU going offline.  These orphaned callbacks have been moved
+        to an arbitrarily chosen online CPU.
 
-o       "dl" is the number of times that we failed to update the "d"
-        counter.
+o       "ca" is the number of RCU callbacks that have been adopted due to
+        other CPUs going offline.  Note that ci+co-ca+ql is the number of
+        RCU callbacks registered on this CPU.
 
-o       "dx" is the number of times that we succeeded in updating
-        the "d" counter.
+There is also an rcu/rcudata.csv file with the same information in
+comma-separated-variable spreadsheet format.
 
 
-The output of "cat rcu/rcu_preempt/rcugp" looks as follows:
+The output of "cat rcu/rcugp" looks as follows:
 
-completed=31249  gpnum=31250  age=1  max=18
+rcu_sched: completed=33062  gpnum=33063
+rcu_bh: completed=464  gpnum=464
 
-These fields are taken from the rcu_state structure, and are as follows:
+Again, this output is for both "rcu_sched" and "rcu_bh".  Note that
+kernels built with CONFIG_TREE_PREEMPT_RCU will have an additional
+"rcu_preempt" line.  The fields are taken from the rcu_state structure,
+and are as follows:
 
 o       "completed" is the number of grace periods that have completed.
         It is comparable to the "c" field from rcu/rcudata in that a
@@ -286,42 +224,44 @@ o	"completed" is the number of grace periods that have completed.
         that the corresponding RCU grace period has completed.
 
 o       "gpnum" is the number of grace periods that have started.  It is
-        similarly comparable to the "g" field from rcu/rcudata in that
-        a CPU whose "g" field matches the value of "gpnum" is aware that
-        the corresponding RCU grace period has started.
-
-        If these two fields are equal, then there is no grace period
-        in progress, in other words, RCU is idle.  On the other hand,
-        if the two fields differ (as they are above), then an RCU grace
-        period is in progress.
+        comparable to the "g" field from rcu/rcudata in that a CPU
+        whose "g" field matches the value of "gpnum" is aware that the
+        corresponding RCU grace period has started.
 
-o       "age" is the number of jiffies that the current grace period
-        has extended for, or zero if there is no grace period currently
-        in effect.
+        If these two fields are equal (as they are for "rcu_bh" above),
+        then there is no grace period in progress, in other words, RCU
+        is idle.  On the other hand, if the two fields differ (as they
+        do for "rcu_sched" above), then an RCU grace period is in progress.
 
-o       "max" is the age in jiffies of the longest-duration grace period
-        thus far.
 
-The output of "cat rcu/rcu_preempt/rcuhier" looks as follows:
+The output of "cat rcu/rcuhier" looks as follows, with very long lines:
 
-c=14407 g=14408 s=0 jfq=2 j=c863 nfqs=12040/nfqsng=0(12040) fqlh=1051 oqlen=0/0
-3/3 ..>. 0:7 ^0
-e/e ..>. 0:3 ^0    d/d ..>. 4:7 ^1
+c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6
+1/1 ..>. 0:127 ^0
+3/3 ..>. 0:35 ^0    0/0 ..>. 36:71 ^1    0/0 ..>. 72:107 ^2    0/0 ..>. 108:127 ^3
+3/3f ..>. 0:5 ^0    2/3 ..>. 6:11 ^1    0/0 ..>. 12:17 ^2    0/0 ..>. 18:23 ^3    0/0 ..>. 24:29 ^4    0/0 ..>. 30:35 ^5    0/0 ..>. 36:41 ^0    0/0 ..>. 42:47 ^1    0/0 ..>. 48:53 ^2    0/0 ..>. 54:59 ^3    0/0 ..>. 60:65 ^4    0/0 ..>. 66:71 ^5    0/0 ..>. 72:77 ^0    0/0 ..>. 78:83 ^1    0/0 ..>. 84:89 ^2    0/0 ..>. 90:95 ^3    0/0 ..>. 96:101 ^4    0/0 ..>. 102:107 ^5    0/0 ..>. 108:113 ^0    0/0 ..>. 114:119 ^1    0/0 ..>. 120:125 ^2    0/0 ..>. 126:127 ^3
+rcu_bh:
+c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0
+0/1 ..>. 0:127 ^0
+0/3 ..>. 0:35 ^0    0/0 ..>. 36:71 ^1    0/0 ..>. 72:107 ^2    0/0 ..>. 108:127 ^3
+0/3f ..>. 0:5 ^0    0/3 ..>. 6:11 ^1    0/0 ..>. 12:17 ^2    0/0 ..>. 18:23 ^3    0/0 ..>. 24:29 ^4    0/0 ..>. 30:35 ^5    0/0 ..>. 36:41 ^0    0/0 ..>. 42:47 ^1    0/0 ..>. 48:53 ^2    0/0 ..>. 54:59 ^3    0/0 ..>. 60:65 ^4    0/0 ..>. 66:71 ^5    0/0 ..>. 72:77 ^0    0/0 ..>. 78:83 ^1    0/0 ..>. 84:89 ^2    0/0 ..>. 90:95 ^3    0/0 ..>. 96:101 ^4    0/0 ..>. 102:107 ^5    0/0 ..>. 108:113 ^0    0/0 ..>. 114:119 ^1    0/0 ..>. 120:125 ^2    0/0 ..>. 126:127 ^3
 
-The fields are as follows:
+This is once again split into "rcu_sched" and "rcu_bh" portions,
+and CONFIG_TREE_PREEMPT_RCU kernels will again have an additional
+"rcu_preempt" section.  The fields are as follows:
 
-o       "c" is exactly the same as "completed" under rcu/rcu_preempt/rcugp.
+o       "c" is exactly the same as "completed" under rcu/rcugp.
 
-o       "g" is exactly the same as "gpnum" under rcu/rcu_preempt/rcugp.
+o       "g" is exactly the same as "gpnum" under rcu/rcugp.
 
-o       "s" is the current state of the force_quiescent_state()
+o       "s" is the "signaled" state that drives force_quiescent_state()'s
         state machine.
 
 o       "jfq" is the number of jiffies remaining for this grace period
         before force_quiescent_state() is invoked to help push things
-        along.  Note that CPUs in idle mode throughout the grace period
-        will not report on their own, but rather must be check by some
-        other CPU via force_quiescent_state().
+        along.  Note that CPUs in dyntick-idle mode throughout the grace
+        period will not report on their own, but rather must be check by
+        some other CPU via force_quiescent_state().
 
 o       "j" is the low-order four hex digits of the jiffies counter.
         Yes, Paul did run into a number of problems that turned out to
@@ -332,8 +272,7 @@ o	"nfqs" is the number of calls to force_quiescent_state() since
 
 o       "nfqsng" is the number of useless calls to force_quiescent_state(),
         where there wasn't actually a grace period active.  This can
-        no longer happen due to grace-period processing being pushed
-        into a kthread.  The number in parentheses is the difference
+        happen due to races.  The number in parentheses is the difference
         between "nfqs" and "nfqsng", or the number of times that
         force_quiescent_state() actually did some real work.
 
@@ -341,27 +280,28 @@ o	"fqlh" is the number of calls to force_quiescent_state() that
         exited immediately (without even being counted in nfqs above)
         due to contention on ->fqslock.
 
-o       Each element of the form "3/3 ..>. 0:7 ^0" represents one rcu_node
-        structure.  Each line represents one level of the hierarchy,
-        from root to leaves.  It is best to think of the rcu_data
-        structures as forming yet another level after the leaves.
-        Note that there might be either one, two, three, or even four
-        levels of rcu_node structures, depending on the relationship
-        between CONFIG_RCU_FANOUT, CONFIG_RCU_FANOUT_LEAF (possibly
-        adjusted using the rcu_fanout_leaf kernel boot parameter), and
-        CONFIG_NR_CPUS (possibly adjusted using the nr_cpu_ids count of
-        possible CPUs for the booting hardware).
+o       Each element of the form "1/1 0:127 ^0" represents one struct
+        rcu_node.  Each line represents one level of the hierarchy, from
+        root to leaves.  It is best to think of the rcu_data structures
+        as forming yet another level after the leaves.  Note that there
+        might be either one, two, or three levels of rcu_node structures,
+        depending on the relationship between CONFIG_RCU_FANOUT and
+        CONFIG_NR_CPUS.
 
         o       The numbers separated by the "/" are the qsmask followed
                 by the qsmaskinit.  The qsmask will have one bit
-                set for each entity in the next lower level that has
-                not yet checked in for the current grace period ("e"
-                indicating CPUs 5, 6, and 7 in the example above).
+                set for each entity in the next lower level that
+                has not yet checked in for the current grace period.
                 The qsmaskinit will have one bit for each entity that is
                 currently expected to check in during each grace period.
                 The value of qsmaskinit is assigned to that of qsmask
                 at the beginning of each grace period.
 
+                For example, for "rcu_sched", the qsmask of the first
+                entry of the lowest level is 0x14, meaning that we
+                are still waiting for CPUs 2 and 4 to check in for the
+                current grace period.
+
         o       The characters separated by the ">" indicate the state
                 of the blocked-tasks lists.  A "G" preceding the ">"
                 indicates that at least one task blocked in an RCU
@@ -376,39 +316,48 @@ o	Each element of the form "3/3 ..>. 0:7 ^0" represents one rcu_node
                 A "." character appears if the corresponding condition
                 does not hold, so that "..>." indicates that no tasks
                 are blocked.  In contrast, "GE>T" indicates maximal
-                inconvenience from blocked tasks.  CONFIG_TREE_RCU
-                builds of the kernel will always show "..>.".
+                inconvenience from blocked tasks.
 
         o       The numbers separated by the ":" are the range of CPUs
                 served by this struct rcu_node.  This can be helpful
                 in working out how the hierarchy is wired together.
 
-                For example, the example rcu_node structure shown above
-                has "0:7", indicating that it covers CPUs 0 through 7.
+                For example, the first entry at the lowest level shows
+                "0:5", indicating that it covers CPUs 0 through 5.
 
         o       The number after the "^" indicates the bit in the
-                next higher level rcu_node structure that this rcu_node
-                structure corresponds to.  For example, the "d/d ..>. 4:7
-                ^1" has a "1" in this position, indicating that it
-                corresponds to the "1" bit in the "3" shown in the
-                "3/3 ..>. 0:7 ^0" entry on the next level up.
-
-
-The output of "cat rcu/rcu_sched/rcu_pending" looks as follows:
-
-  0!np=26111 qsp=29 rpq=5386 cbr=1 cng=570 gpc=3674 gps=577 nn=15903
-  1!np=28913 qsp=35 rpq=6097 cbr=1 cng=448 gpc=3700 gps=554 nn=18113
-  2!np=32740 qsp=37 rpq=6202 cbr=0 cng=476 gpc=4627 gps=546 nn=20889
-  3 np=23679 qsp=22 rpq=5044 cbr=1 cng=415 gpc=3403 gps=347 nn=14469
-  4!np=30714 qsp=4 rpq=5574 cbr=0 cng=528 gpc=3931 gps=639 nn=20042
-  5 np=28910 qsp=2 rpq=5246 cbr=0 cng=428 gpc=4105 gps=709 nn=18422
-  6!np=38648 qsp=5 rpq=7076 cbr=0 cng=840 gpc=4072 gps=961 nn=25699
-  7 np=37275 qsp=2 rpq=6873 cbr=0 cng=868 gpc=3416 gps=971 nn=25147
-
-The fields are as follows:
-
-o       The leading number is the CPU number, with "!" indicating
-        an offline CPU.
+                next higher level rcu_node structure that this
+                rcu_node structure corresponds to.
+
+                For example, the first entry at the lowest level shows
+                "^0", indicating that it corresponds to bit zero in
+                the first entry at the middle level.
+
+
+The output of "cat rcu/rcu_pending" looks as follows:
+
+rcu_sched:
+  0 np=255892 qsp=53936 rpq=85 cbr=0 cng=14417 gpc=10033 gps=24320 nf=6445 nn=146741
+  1 np=261224 qsp=54638 rpq=33 cbr=0 cng=25723 gpc=16310 gps=2849 nf=5912 nn=155792
+  2 np=237496 qsp=49664 rpq=23 cbr=0 cng=2762 gpc=45478 gps=1762 nf=1201 nn=136629
+  3 np=236249 qsp=48766 rpq=98 cbr=0 cng=286 gpc=48049 gps=1218 nf=207 nn=137723
+  4 np=221310 qsp=46850 rpq=7 cbr=0 cng=26 gpc=43161 gps=4634 nf=3529 nn=123110
+  5 np=237332 qsp=48449 rpq=9 cbr=0 cng=54 gpc=47920 gps=3252 nf=201 nn=137456
+  6 np=219995 qsp=46718 rpq=12 cbr=0 cng=50 gpc=42098 gps=6093 nf=4202 nn=120834
+  7 np=249893 qsp=49390 rpq=42 cbr=0 cng=72 gpc=38400 gps=17102 nf=41 nn=144888
+rcu_bh:
+  0 np=146741 qsp=1419 rpq=6 cbr=0 cng=6 gpc=0 gps=0 nf=2 nn=145314
+  1 np=155792 qsp=12597 rpq=3 cbr=0 cng=0 gpc=4 gps=8 nf=3 nn=143180
+  2 np=136629 qsp=18680 rpq=1 cbr=0 cng=0 gpc=7 gps=6 nf=0 nn=117936
+  3 np=137723 qsp=2843 rpq=0 cbr=0 cng=0 gpc=10 gps=7 nf=0 nn=134863
+  4 np=123110 qsp=12433 rpq=0 cbr=0 cng=0 gpc=4 gps=2 nf=0 nn=110671
+  5 np=137456 qsp=4210 rpq=1 cbr=0 cng=0 gpc=6 gps=5 nf=0 nn=133235
+  6 np=120834 qsp=9902 rpq=2 cbr=0 cng=0 gpc=6 gps=3 nf=2 nn=110921
+  7 np=144888 qsp=26336 rpq=0 cbr=0 cng=0 gpc=8 gps=2 nf=0 nn=118542
+
+As always, this is once again split into "rcu_sched" and "rcu_bh"
+portions, with CONFIG_TREE_PREEMPT_RCU kernels having an additional
+"rcu_preempt" section.  The fields are as follows:
 
 o       "np" is the number of times that __rcu_pending() has been invoked
         for the corresponding flavor of RCU.
@@ -432,23 +381,49 @@ o	"gpc" is the number of times that an old grace period had
 o       "gps" is the number of times that a new grace period had started,
         but this CPU was not yet aware of it.
 
-o       "nn" is the number of times that this CPU needed nothing.
+o       "nf" is the number of times that this CPU suspected that the
+        current grace period had run for too long, and thus needed to
+        be forced.
+
+        Please note that "forcing" consists of sending resched IPIs
+        to holdout CPUs.  If that CPU really still is in an old RCU
+        read-side critical section, then we really do have to wait for it.
+        The assumption behing "forcing" is that the CPU is not still in
+        an old RCU read-side critical section, but has not yet responded
+        for some other reason.
+
+o       "nn" is the number of times that this CPU needed nothing.  Alert
+        readers will note that the rcu "nn" number for a given CPU very
+        closely matches the rcu_bh "np" number for that same CPU.  This
+        is due to short-circuit evaluation in rcu_pending().
+
+
+The output of "cat rcu/rcutorture" looks as follows:
+
+rcutorture test sequence: 0 (test in progress)
+rcutorture update version number: 615
+
+The first line shows the number of rcutorture tests that have completed
+since boot.  If a test is currently running, the "(test in progress)"
+string will appear as shown above.  The second line shows the number of
+update cycles that the current test has started, or zero if there is
+no test in progress.
 
 
 The output of "cat rcu/rcuboost" looks as follows:
 
-0:3 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=c864 bt=c894
-    balk: nt=0 egt=4695 bt=0 nb=0 ny=56 nos=0
-4:7 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=c864 bt=c894
-    balk: nt=0 egt=6541 bt=0 nb=0 ny=126 nos=0
+0:5 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=2f95 bt=300f
+     balk: nt=0 egt=989 bt=0 nb=0 ny=0 nos=16
+6:7 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=2f95 bt=300f
+     balk: nt=0 egt=225 bt=0 nb=0 ny=0 nos=6
 
 This information is output only for rcu_preempt.  Each two-line entry
 corresponds to a leaf rcu_node strcuture.  The fields are as follows:
 
 o       "n:m" is the CPU-number range for the corresponding two-line
         entry.  In the sample output above, the first entry covers
-        CPUs zero through three and the second entry covers CPUs four
-        through seven.
+        CPUs zero through five and the second entry covers CPUs 6
+        and 7.
 
 o       "tasks=TNEB" gives the state of the various segments of the
         rnp->blocked_tasks list:
diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
index 0cc7820967f..6ef692667e2 100644
--- a/Documentation/RCU/whatisRCU.txt
+++ b/Documentation/RCU/whatisRCU.txt
@@ -4,7 +4,6 @@ to start learning about RCU:
 1.      What is RCU, Fundamentally?  http://lwn.net/Articles/262464/
 2.      What is RCU? Part 2: Usage   http://lwn.net/Articles/263130/
 3.      RCU part 3: the RCU API      http://lwn.net/Articles/264090/
-4.      The RCU API, 2010 Edition    http://lwn.net/Articles/418853/
 
 
 What is RCU?
@@ -499,8 +498,6 @@ The foo_reclaim() function might appear as follows:
         {
                 struct foo *fp = container_of(rp, struct foo, rcu);
 
-                foo_cleanup(fp->a);
-
                 kfree(fp);
         }
 
@@ -523,12 +520,6 @@ o	Use call_rcu() -after- removing a data element from an
         read-side critical sections that might be referencing that
         data item.
 
-If the callback for call_rcu() is not doing anything more than calling
-kfree() on the structure, you can use kfree_rcu() instead of call_rcu()
-to avoid having to write your own callback:
-
-        kfree_rcu(old_fp, rcu);
-
 Again, see checklist.txt for additional rules governing the use of RCU.
 
 
@@ -781,8 +772,8 @@ a single atomic update, converting to RCU will require special care.
 
 Also, the presence of synchronize_rcu() means that the RCU version of
 delete() can now block.  If this is a problem, there is a callback-based
-mechanism that never blocks, namely call_rcu() or kfree_rcu(), that can
-be used in place of synchronize_rcu().
+mechanism that never blocks, namely call_rcu(), that can be used in
+place of synchronize_rcu().
 
 
 7.  FULL LIST OF RCU APIs
@@ -797,7 +788,9 @@ RCU list traversal:
         list_for_each_entry_rcu
         hlist_for_each_entry_rcu
         hlist_nulls_for_each_entry_rcu
-        list_for_each_entry_continue_rcu
+
+        list_for_each_continue_rcu      (to be deprecated in favor of new
+                                         list_for_each_entry_continue_rcu)
 
 RCU pointer/list update:
 
@@ -819,7 +812,6 @@ RCU:	Critical sections	Grace period		Barrier
         rcu_read_unlock         synchronize_rcu
         rcu_dereference         synchronize_rcu_expedited
                                 call_rcu
-                                kfree_rcu
 
 
 bh:     Critical sections       Grace period            Barrier
@@ -840,10 +832,8 @@ sched:	Critical sections	Grace period		Barrier
 
 SRCU:   Critical sections       Grace period            Barrier
 
-        srcu_read_lock          synchronize_srcu        srcu_barrier
-        srcu_read_unlock        call_srcu
-        srcu_read_lock_raw      synchronize_srcu_expedited
-        srcu_read_unlock_raw
+        srcu_read_lock          synchronize_srcu        N/A
+        srcu_read_unlock        synchronize_srcu_expedited
         srcu_dereference
 
 SRCU:   Initialization/cleanup
@@ -865,38 +855,27 @@ list can be helpful:
 
 a.      Will readers need to block?  If so, you need SRCU.
 
-b.      Is it necessary to start a read-side critical section in a
-        hardirq handler or exception handler, and then to complete
-        this read-side critical section in the task that was
-        interrupted?  If so, you need SRCU's srcu_read_lock_raw() and
-        srcu_read_unlock_raw() primitives.
-
-c.      What about the -rt patchset?  If readers would need to block
+b.      What about the -rt patchset?  If readers would need to block
         in an non-rt kernel, you need SRCU.  If readers would block
         in a -rt kernel, but not in a non-rt kernel, SRCU is not
         necessary.
 
-d.      Do you need to treat NMI handlers, hardirq handlers,
+c.      Do you need to treat NMI handlers, hardirq handlers,
         and code segments with preemption disabled (whether
         via preempt_disable(), local_irq_save(), local_bh_disable(),
         or some other mechanism) as if they were explicit RCU readers?
-        If so, RCU-sched is the only choice that will work for you.
+        If so, you need RCU-sched.
 
-e.      Do you need RCU grace periods to complete even in the face
+d.      Do you need RCU grace periods to complete even in the face
         of softirq monopolization of one or more of the CPUs?  For
         example, is your code subject to network-based denial-of-service
         attacks?  If so, you need RCU-bh.
 
-f.      Is your workload too update-intensive for normal use of
+e.      Is your workload too update-intensive for normal use of
         RCU, but inappropriate for other synchronization mechanisms?
         If so, consider SLAB_DESTROY_BY_RCU.  But please be careful!
 
-g.      Do you need read-side critical sections that are respected
-        even though they are in the middle of the idle loop, during
-        user-mode execution, or on an offlined CPU?  If so, SRCU is the
-        only choice that will work for you.
-
-h.      Otherwise, use RCU.
+f.      Otherwise, use RCU.
 
 Of course, this all assumes that you have determined that RCU is in fact
 the right tool for your job.