On Tue, Jun 22, 2021 at 05:35:21PM +0530, Neeraj Upadhyay wrote: > In addition to irq and softirq state, check rcu_bh_lock_map > state, to decide whether RCU bh lock is held. > > Signed-off-by: Neeraj Upadhyay <neeraju@xxxxxxxxxxxxxx> My initial reaction was that "in_softirq() || irqs_disabled()" covers it because rcu_read_lock_bh() disables BH. But you are right that it does seem a bit silly to ignore lockdep. So would it also make sense to have a WARN_ON_ONCE() if lockdep claims we are under rcu_read_lock_bh() protection, but "in_softirq() || irqs_disabled()" think otherwise? Thanx, Paul > --- > kernel/rcu/update.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c > index c21b38c..d416f1c 100644 > --- a/kernel/rcu/update.c > +++ b/kernel/rcu/update.c > @@ -333,7 +333,7 @@ int rcu_read_lock_bh_held(void) > > if (rcu_read_lock_held_common(&ret)) > return ret; > - return in_softirq() || irqs_disabled(); > + return lock_is_held(&rcu_bh_lock_map) || in_softirq() || irqs_disabled(); > } > EXPORT_SYMBOL_GPL(rcu_read_lock_bh_held); > > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > hosted by The Linux Foundation >
