Re: [PATCH tip/core/rcu 09/10] rcu: update obsoletercu_read_lock() comment.

[Mathieu Desnoyers]

* Paul E. McKenney (paulmck@xxxxxxxxxxxxxxxxxx) wrote:
> The comment says that blocking is illegal in rcu_read_lock()-style
> RCU read-side critical sections, which is no longer entirely true
> given preemptible RCU.  This commit provides a fix.
> 
> Suggested-by: David Miller <davem@xxxxxxxxxxxxx>
> Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
> ---
>  include/linux/rcupdate.h |   15 ++++++++++++++-
>  1 files changed, 14 insertions(+), 1 deletions(-)
> 
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 24b8966..d7af96e 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -458,7 +458,20 @@ extern int rcu_my_thread_group_empty(void);
>   * will be deferred until the outermost RCU read-side critical section
>   * completes.
>   *
> - * It is illegal to block while in an RCU read-side critical section.
> + * You can avoid reading and understanding the next paragraph by
> + * following this rule: don't put anything in an rcu_read_lock() RCU
> + * read-side critical section that would block in a !PREEMPT kernel.
> + * But if you want the full story, read on!
> + *
> + * In non-preemptible RCU implementations (TREE_RCU and TINY_RCU), it
> + * is illegal to block while in an RCU read-side critical section.  In
> + * preemptible RCU implementations (TREE_PREEMPT_RCU and TINY_PREEMPT_RCU)
> + * in CONFIG_PREEMPT kernel builds, RCU read-side critical sections may
> + * be preempted, but explicit blocking is illegal.  Finally, in preemptible
> + * RCU implementations in real-time (CONFIG_PREEMPT_RT) kernel builds,
> + * RCU read-side critical sections may be preempted and they may also
> + * block, but only when acquiring spinlocks that are subject to priority
> + * inheritance.

It might be good to add a note about locking chain dependency that is
created in the RT case, e.g., the lock we are sharing with another
context in preempt RT is subject to the same rules as the RCU C.S.. It
should never call synchronize_rcu(); this would cause a RCU+lock-induced
deadlock.

I must admit, however, that because calling synchronize_rcu() from
spinlocks is already forbidden, this is already implied.

Thanks,

Mathieu

>   */
>  static inline void rcu_read_lock(void)
>  {
> -- 
> 1.7.0.6
> 

-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/