linux-kernel - Re: [PATCH rcu 3/9] rcu: Add mutex for rcu boost kthread spawning and affinity setting

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

Message-ID: <20220211154344.GD588079@lothringen>
Date:   Fri, 11 Feb 2022 16:43:44 +0100
From:   Frederic Weisbecker <frederic@...nel.org>
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     rcu@...r.kernel.org, linux-kernel@...r.kernel.org,
        kernel-team@...com, rostedt@...dmis.org,
        David Woodhouse <dwmw@...zon.co.uk>
Subject: Re: [PATCH rcu 3/9] rcu: Add mutex for rcu boost kthread spawning
 and affinity setting

On Fri, Feb 11, 2022 at 07:42:03AM -0800, Paul E. McKenney wrote:
> On Fri, Feb 11, 2022 at 04:11:48PM +0100, Frederic Weisbecker wrote:
> > On Fri, Feb 11, 2022 at 03:57:57PM +0100, Frederic Weisbecker wrote:
> > > On Fri, Feb 04, 2022 at 03:07:59PM -0800, Paul E. McKenney wrote:
> > > > From: David Woodhouse <dwmw@...zon.co.uk>
> > > > 
> > > > As we handle parallel CPU bringup, we will need to take care to avoid
> > > > spawning multiple boost threads, or race conditions when setting their
> > > > affinity. Spotted by Paul McKenney.
> > > > 
> > > > Signed-off-by: David Woodhouse <dwmw@...zon.co.uk>
> > > > Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
> > > 
> > > Reviewed-by: Frederic Weisbecker <frederic@...nel.org>
> > > 
> > > Speaking of, we have:
> > > 
> > > rcu_init()
> > >    for_each_online_cpu(cpu) // should be boot CPU only at this stage ?
> > >        rcutree_prepare_cpu(cpu)
> > >            rcu_spawn_one_boost_kthread(cpu)
> > > 
> > > 
> > > early_initcall()
> > >     rcu_spawn_gp_kthread()
> > >         rcu_spawn_boost_kthreads()
> > > 	    rcu_for_each_leaf_node(rnp)
> > > 	        rcu_rnp_online_cpus(rnp) // as above, only boot CPU at this stage.
> > >                     rcu_spawn_one_boost_kthread(cpu)
> > > 
> > > cpu_up()
> > >     rcutree_prepare_cpu(cpu)
> > >         rcu_spawn_one_boost_kthread(cpu)
> > > 
> > > 
> > > My guess is that we could remove rcu_spawn_boost_kthreads() and simplify
> > > rcu_init(). Something like this (untested yet):
> 
> If you also add a WARN_ON() for more than one CPU being online at
> rcu_init() time, I am good with this approach.  The main danger that
> the pre-rcu_init() portion of the boot time becomes the long straw in
> the eternal quest to make systems boot faster, but it is not hard to
> put it back.  Hence the WARN_ON() to make it clear that adjustment
> is needed.  ;-)
> 
> 							Thanx, Paul

Make sense. On my TODO list then.

Thanks!