linux-kernel - Re: [PATCH 3/8] refscale: Add local_bh

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] [day] [month] [year] [list]

Message-ID: <758f6e84-e707-452c-b174-f9d03efb6819@paulmck-laptop>
Date: Wed, 12 Nov 2025 09:41:43 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: rcu@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-team@...a.com,
	rostedt@...dmis.org
Subject: Re: [PATCH 3/8] refscale: Add local_bh_disable() readers

On Wed, Nov 12, 2025 at 10:14:52AM +0100, Sebastian Andrzej Siewior wrote:
> 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.

Mostly just trying to measure the overhead of a local_bh_disable()
and local_bh_enable() pair.  Yes, I understand that this is a bit
iffy these days, but it at least gets us some indication of problems
like this one:
https://lore.kernel.org/all/e7d539ed-ced0-4b96-8ecd-048a5b803b85@paulmck-laptop/

> 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 ;) 

Not necessary most of the time, anyway.  ;-)

> 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.

Very good, thank you!  I am keeping it as an "EXP" (as in "experimental")
commit in my -rcu tree for the time being, given that it sounds like
you are looking to fix this within -rt.

							Thanx, Paul