hw-breakpoint: Keep track of dr7 local enable bits

[safe/jmp/linux-2.6] / Documentation / RCU / checklist.txt

diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
index 6e25340..51525a3 100644 (file)
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@@ -11,7 +11,10 @@ over a rather long period of time, but improvements are always welcome!
        structure is updated more than about 10% of the time, then
        you should strongly consider some other approach, unless
        detailed performance measurements show that RCU is nonetheless
-       the right tool for the job.
+       the right tool for the job.  Yes, you might think of RCU
+       as simply cutting overhead off of the readers and imposing it
+       on the writers.  That is exactly why normal uses of RCU will
+       do much more reading than updating.
 
        Another exception is where performance is not an issue, and RCU
        provides a simpler implementation.  An example of this situation
@@ -240,10 +243,11 @@ over a rather long period of time, but improvements are always welcome!
        instead need to use synchronize_irq() or synchronize_sched().
 
 12.    Any lock acquired by an RCU callback must be acquired elsewhere
-       with irq disabled, e.g., via spin_lock_irqsave().  Failing to
-       disable irq on a given acquisition of that lock will result in
-       deadlock as soon as the RCU callback happens to interrupt that
-       acquisition's critical section.
+       with softirq disabled, e.g., via spin_lock_irqsave(),
+       spin_lock_bh(), etc.  Failing to disable irq on a given
+       acquisition of that lock will result in deadlock as soon as the
+       RCU callback happens to interrupt that acquisition's critical
+       section.
 
 13.    RCU callbacks can be and are executed in parallel.  In many cases,
        the callback code simply wrappers around kfree(), so that this
@@ -298,3 +302,21 @@ over a rather long period of time, but improvements are always welcome!
 
        Note that, rcu_assign_pointer() and rcu_dereference() relate to
        SRCU just as they do to other forms of RCU.
+
+15.    The whole point of call_rcu(), synchronize_rcu(), and friends
+       is to wait until all pre-existing readers have finished before
+       carrying out some otherwise-destructive operation.  It is
+       therefore critically important to -first- remove any path
+       that readers can follow that could be affected by the
+       destructive operation, and -only- -then- invoke call_rcu(),
+       synchronize_rcu(), or friends.
+
+       Because these primitives only wait for pre-existing readers,
+       it is the caller's responsibility to guarantee safety to
+       any subsequent readers.
+
+16.    The various RCU read-side primitives do -not- contain memory
+       barriers.  The CPU (and in some cases, the compiler) is free
+       to reorder code into and out of RCU read-side critical sections.
+       It is the responsibility of the RCU update-side primitives to
+       deal with this.