linux-kernel - Re: [PATCH v6 6/6] timers: Exclude isolated cpus from timer migation

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: <1bc41a7a5bd46860318b0417fa27121758f28448.camel@redhat.com>
Date: Tue, 24 Jun 2025 16:06:41 +0200
From: Gabriele Monaco <gmonaco@...hat.com>
To: Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org, 
 Anna-Maria Behnsen <anna-maria@...utronix.de>, Frederic Weisbecker
 <frederic@...nel.org>, Waiman Long <longman@...hat.com>
Subject: Re: [PATCH v6 6/6] timers: Exclude isolated cpus from timer migation



On Tue, 2025-06-24 at 15:20 +0200, Thomas Gleixner wrote:
> On Tue, Jun 24 2025 at 10:05, Gabriele Monaco wrote:
> 
> Please trim your replies. It's a pain to scroll through 160 quotes
> lines
> to find the gist of the mail...
> 
> > On Fri, 2025-06-20 at 19:00 +0200, Thomas Gleixner wrote:
> > > > +	if ((!housekeeping_cpu(cpu, HK_TYPE_DOMAIN) ||
> > > > +	     cpuset_cpu_is_isolated(cpu)) &&
> > > > +	    housekeeping_cpu(cpu, HK_TYPE_KERNEL_NOISE) &&
> > > > +	    tick_nohz_cpu_hotpluggable(cpu))
> > > > +		return 0;
> > > 
> > > Same nonsense as above.
> > > 
> > tmigr_cpu_available is called at boot time and is applying also the
> > boot time isolation parameters (tmigr_isolated_exclude_cpumask is
> > only
> > used by the cpuset code).
> > 
> > Now let's assume a machine booted with the arguments isolcpus=0-3
> > nohz_full=5-7.
> > 
> > Without checking for tick_nohz_cpu_hotpluggable() here, we would
> > not
> > set the tick cpu (0) as available at boot, ending up in the
> > unwanted
> > corner cases discussed in the v5 of the series.
> > 
> > I could remove this call here (which is mostly redundant after
> > boot)
> > and enable explicitly the tick cpu in another way, but this still
> > seems
> > cleaner to me.
> > 
> > Does it make sense to you? Is the comment in the code unclear?
> 
> It does not make sense and the comment does not change that.
> 
> The point is that tmigr_init() is an early initcall which is invoked
> before SMP is initialized and APs are brought up.
> 
> At this point CPU0 can neither be isolated nor nohz full for obvious
> reasons, no?
> 

Right, but as far as I understood, the first call to 
tmigr_set_cpu_available() happens after the isolcpus parameter has been
parsed so we know at least cpu0 is going to be isolated.

On my machine it works reliably this way. I'm a bit lost in the init
code but seeing housekeeping_init() before rcu_init(), which in turn
should be required for some RCU-related early_initcalls, makes me
believe this order is guaranteed to be respected.
Or am I missing something?

Thanks,
Gabriele