linux-kernel - Re: [PATCH tip/core/rcu 09/10] rcu: update obsolete rcu_read

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 16 Aug 2010 10:45:32 -0400
From:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, laijs@...fujitsu.com,
	dipankar@...ibm.com, akpm@...ux-foundation.org,
	josh@...htriplett.org, dvhltc@...ibm.com, niv@...ibm.com,
	tglx@...utronix.de, peterz@...radead.org, rostedt@...dmis.org,
	Valdis.Kletnieks@...edu, dhowells@...hat.com,
	eric.dumazet@...il.com
Subject: Re: [PATCH tip/core/rcu 09/10] rcu: update obsolete
	rcu_read_lock() comment.

* Paul E. McKenney (paulmck@...ux.vnet.ibm.com) 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@...emloft.net>
> Signed-off-by: Paul E. McKenney <paulmck@...ux.vnet.ibm.com>
> ---
>  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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/