| commit | d8936c0b7e29510ce8f5c85ff5fcc592a938e860 | [log] [tgz] |
|---|---|---|
| author | Paul E. McKenney <paulmck@linux.vnet.ibm.com> | Mon Feb 15 17:29:47 2016 -0800 |
| committer | Paul E. McKenney <paulmck@linux.vnet.ibm.com> | Thu Mar 31 13:33:20 2016 -0700 |
| tree | 013f527bbb3972263e4428eb5b9e3dc762c76c92 | |
| parent | f43b62542eb61a52d97d6b82a786a912fa5e6c51 [diff] |
documentation: Explain why rcu_read_lock() needs no barrier() This commit adds a Quick Quiz whose answer explains why the compiler code reordering enabled by CONFIG_PREEMPT=n's empty rcu_read_lock() and rcu_read_unlock() functions does not hinder RCU's ability to figure out which RCU read-side critical sections have completed and not. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>