Version 3 of the SRCU patchset.
This patch incorporates a number of improvements, many of which came
up in off-list discussions with Alan Stern. Neither of us are sure
why these discussions ended up off-list, so I have summarized them
below.
o Fixes some "zombie code" -- excess curly braces and the like.
o Gets rid of the double-flip in favor of an additional
synchronize_sched(). This turned out to be safe, despite
my saying otherwise at http://lkml.org/lkml/2006/6/27/486.
The trick that I was missing is that synchronize_sched()
forces all CPUs to execute at least one memory barrier during
the synchronize_sched()'s execution, which forces all CPUs
to see synchronize_srcu()'s counter increment as happening
after any memory manipulations prior to the synchronize_srcu().
Upgraded comments to indicate what the synchronize_sched()
calls are needed for.
o Added a barrier() to both srcu_read_lock() and srcu_read_unlock()
to prevent the compiler from performing optimizations that
would cause the critical section to move outside of the
enclosing srcu_read_lock() and srcu_read_unlock().
However, these barrier()s in srcu_read_lock() and srcu_read_unlock()
are needed only in non-CONFIG_PREEMPT kernels, so they compile
to nothing in CONFIG_PREEMPT kernels (where the preempt_disable()
and preempt_enable() calls supply the needed barrier() call).
o Added a check to synchronize_srcu() that permits this primitive
to take advantage of grace periods induced by concurrent executions
in other tasks. This can be useful in cases where you are
using a single srcu_struct to handle all the individually-locked
chains of a hash table, for example.
o cleanup_srcu_struct() now contains error checks to catch cases
where readers are still using the srcu_struct in question.
It does a WARN_ON() and leaks the srcu_struct's per-CPU data
in that case.
o There is an srcu_readers_active() that returns the number of
readers (approximate!) currently using the specified srcu_struct.
This can be useful when terminating use of an srcu_struct, e.g.,
at module-unload time.
o Improved the RCU torture tests, increasing the skew on reader
times and providing implementation-specific delay functions.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
