Re: [PATCH RT v2 1/3] rcu: Acquire RCU lock when disabling BHs
From: Paul E. McKenney <hidden>
Date: 2019-08-23 02:54:31
Also in:
lkml
On Thu, Aug 22, 2019 at 09:36:21PM -0500, Scott Wood wrote:
On Wed, 2019-08-21 at 16:33 -0700, Paul E. McKenney wrote:quoted
On Wed, Aug 21, 2019 at 06:19:04PM -0500, Scott Wood wrote:quoted
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h index 388ace315f32..d6e357378732 100644 --- a/include/linux/rcupdate.h +++ b/include/linux/rcupdate.h@@ -615,10 +615,12 @@ static inline void rcu_read_unlock(void) static inline void rcu_read_lock_bh(void) { local_bh_disable(); +#ifndef CONFIG_PREEMPT_RT_FULL __acquire(RCU_BH); rcu_lock_acquire(&rcu_bh_lock_map); RCU_LOCKDEP_WARN(!rcu_is_watching(), "rcu_read_lock_bh() used illegally while idle"); +#endifAny chance of this using "if (!IS_ENABLED(CONFIG_PREEMPT_RT_FULL))"? We should be OK providing a do-nothing __maybe_unused rcu_bh_lock_map for lockdep-enabled -rt kernels, right?OK.quoted
quoted
@@ -185,8 +189,10 @@ void __local_bh_enable_ip(unsigned long ip,quoted
quoted
unsigned int cnt)WARN_ON_ONCE(count < 0); local_irq_enable(); - if (!in_atomic()) + if (!in_atomic()) { + rcu_read_unlock(); local_unlock(bh_lock); + }The return from in_atomic() is guaranteed to be the same at local_bh_enable() time as was at the call to the corresponding local_bh_disable()?That's an existing requirement on RT (which rcutorture currently violates) due to bh_lock.quoted
I could have sworn that I ran afoul of this last year. Might these added rcu_read_lock() and rcu_read_unlock() calls need to check for CONFIG_PREEMPT_RT_FULL?This code is already under a PREEMPT_RT_FULL ifdef.
Good enough, then! Thanx, Paul