Messages in this thread Patch in this message | | | Date | Tue, 22 Jun 2021 10:58:55 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH] rcu: update: Check rcu_bh_lock_map state in rcu_read_lock_bh_held |
| |
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@codeaurora.org>
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 >
| |