diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2016-12-12 18:09:54 +0100 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2016-12-12 18:09:54 +0100 |
commit | 718c0ddd6aa911fd2a6fb1b6e050fbaee8060e61 (patch) | |
tree | 8f502a67605f864773d96dca7c8c6e1a9fa3f322 /Documentation | |
parent | Merge tag 'cris-for-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/je... (diff) | |
parent | Merge branch 'for-mingo' of git://git.kernel.org/pub/scm/linux/kernel/git/pau... (diff) | |
download | linux-718c0ddd6aa911fd2a6fb1b6e050fbaee8060e61.tar.xz linux-718c0ddd6aa911fd2a6fb1b6e050fbaee8060e61.zip |
Merge branch 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull RCU updates from Ingo Molnar:
"The main RCU changes in this development cycle were:
- Miscellaneous fixes, including a change to call_rcu()'s rcu_head
alignment check.
- Security-motivated list consistency checks, which are disabled by
default behind DEBUG_LIST.
- Torture-test updates.
- Documentation updates, yet again just simple changes"
* 'core-rcu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
torture: Prevent jitter from delaying build-only runs
torture: Remove obsolete files from rcutorture .gitignore
rcu: Don't kick unless grace period or request
rcu: Make expedited grace periods recheck dyntick idle state
torture: Trace long read-side delays
rcu: RCU_TRACE enables event tracing as well as debugfs
rcu: Remove obsolete comment from __call_rcu()
rcu: Remove obsolete rcu_check_callbacks() header comment
rcu: Tighten up __call_rcu() rcu_head alignment check
Documentation/RCU: Fix minor typo
documentation: Present updated RCU guarantee
bug: Avoid Kconfig warning for BUG_ON_DATA_CORRUPTION
lib/Kconfig.debug: Fix typo in select statement
lkdtm: Add tests for struct list corruption
bug: Provide toggle for BUG on data corruption
list: Split list_del() debug checking into separate function
rculist: Consolidate DEBUG_LIST for list_add_rcu()
list: Split list_add() debug checking into separate function
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/RCU/Design/Requirements/Requirements.html | 25 | ||||
-rw-r--r-- | Documentation/RCU/whatisRCU.txt | 2 |
2 files changed, 25 insertions, 2 deletions
diff --git a/Documentation/RCU/Design/Requirements/Requirements.html b/Documentation/RCU/Design/Requirements/Requirements.html index a4d3838130e4..39bcb74ea733 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.html +++ b/Documentation/RCU/Design/Requirements/Requirements.html @@ -547,7 +547,7 @@ The <tt>rcu_access_pointer()</tt> on line 6 is similar to It could reuse a value formerly fetched from this same pointer. It could also fetch the pointer from <tt>gp</tt> in a byte-at-a-time manner, resulting in <i>load tearing</i>, in turn resulting a bytewise - mash-up of two distince pointer values. + mash-up of two distinct pointer values. It might even use value-speculation optimizations, where it makes a wrong guess, but by the time it gets around to checking the value, an update has changed the pointer to match the wrong guess. @@ -659,6 +659,29 @@ systems with more than one CPU: In other words, a given instance of <tt>synchronize_rcu()</tt> can avoid waiting on a given RCU read-side critical section only if it can prove that <tt>synchronize_rcu()</tt> started first. + + <p> + A related question is “When <tt>rcu_read_lock()</tt> + doesn't generate any code, why does it matter how it relates + to a grace period?” + The answer is that it is not the relationship of + <tt>rcu_read_lock()</tt> itself that is important, but rather + the relationship of the code within the enclosed RCU read-side + critical section to the code preceding and following the + grace period. + If we take this viewpoint, then a given RCU read-side critical + section begins before a given grace period when some access + preceding the grace period observes the effect of some access + within the critical section, in which case none of the accesses + within the critical section may observe the effects of any + access following the grace period. + + <p> + As of late 2016, mathematical models of RCU take this + viewpoint, for example, see slides 62 and 63 + of the + <a href="http://www2.rdrop.com/users/paulmck/scalability/paper/LinuxMM.2016.10.04c.LCE.pdf">2016 LinuxCon EU</a> + presentation. </font></td></tr> <tr><td> </td></tr> </table> diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 204422719197..5cbd8b2395b8 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt @@ -237,7 +237,7 @@ rcu_dereference() The reader uses rcu_dereference() to fetch an RCU-protected pointer, which returns a value that may then be safely - dereferenced. Note that rcu_deference() does not actually + dereferenced. Note that rcu_dereference() does not actually dereference the pointer, instead, it protects the pointer for later dereferencing. It also executes any needed memory-barrier instructions for a given CPU architecture. Currently, only Alpha |