On 2025-11-11 11:21:04 [-0800], Paul E. McKenney wrote:
> On Tue, Nov 11, 2025 at 04:38:03PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2025-11-02 14:49:43 [-0800], Paul E. McKenney wrote:
> > > --- a/kernel/rcu/refscale.c
> > > +++ b/kernel/rcu/refscale.c
> > > @@ -636,6 +636,37 @@ static const struct ref_scale_ops jiffies_ops = {
> > > .name = "jiffies"
> > > };
> > >
> > > +static void ref_bh_section(const int nloops)
> > > +{
> > > + int i;
> > > +
> > > + preempt_disable();
> > > + for (i = nloops; i >= 0; i--) {
> > > + local_bh_disable();
> >
> > This (preempt off followed by bh off) may cause warnings. That would be
> > bh is disabled on the CPU, it gets preempted by _this_ which disables
> > first preemption and then bh.
> > I hid the code under CONFIG_PREEMPT_RT_NEEDS_BH_LOCK so it shouldn't be
> > a problem in the long term I think. So just if you see a warning here
> > under RT you know why :)
>
> Huh. Would migrate_disable() be appropriate? Or I suppose I could just
> let it migrate on RT. So how about the fix shown below?
Depends on what you want to achieve. Even with that bh-disable you can
be preempted but you can't migrate to another CPU.
That preempt-disable() will keep the RCU read section open during
bh-disable/ enable but migrate_disable() won't. But this not something I
need to explain to you ;)
If that (to be within a RCU read section) is you intention you could
explicitly add a rcu_read_lock() there.
The change you suggested won't have the problem I mentioned.
> Thanx, Paul
Sebastian
