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: <aFv2mLdH3lNHdKtp@localhost.localdomain>
Date: Wed, 25 Jun 2025 15:16:08 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: Gabriele Monaco <gmonaco@...hat.com>, linux-kernel@...r.kernel.org,
	Anna-Maria Behnsen <anna-maria@...utronix.de>,
	Waiman Long <longman@...hat.com>
Subject: Re: [PATCH v6 6/6] timers: Exclude isolated cpus from timer migation

Le Wed, Jun 25, 2025 at 12:45:32PM +0200, Thomas Gleixner a écrit :
> On Tue, Jun 24 2025 at 16:52, Frederic Weisbecker wrote:
> > Le Tue, Jun 24, 2025 at 04:06:41PM +0200, Gabriele Monaco a écrit :
> >> 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?
> >
> > Right I think you need to keep those checks because if CPU 0 is isolcpus
> > and CPU 5 is nohz_full, CPU 0 will become later the timekeeper and must stay
> > in the tmigr hierarchy.
> >
> > OTOH if CPU 0 is isolcpus and there is no nohz_full CPUs, then CPU 0 doesn't
> > want to go to the hierarchy.
> >
> > cpuset isolated partitions are different because they issue SMP calls whereas
> > isolcpus is defined on boot.
> >
> > An alternative for isolcpus could be to make a late initcall and do the smp
> > calls from there just like is done for cpusets.
> 
> There is zero reason for isolcpus and nohz full muck to be
> active/evaluated during early boot. That's all irrelevant and just
> complicates things further.
> 
> Can we please clean this up and make it a sensible design instead of
> duct taping new functionality into it in completely incomprehensible
> ways?
> 
> Especially under the aspect that all this should become run-time
> modifyable. That requires a run-time switch mechanism anyway, so the
> obvious design choice is to utilize that run-time switch late in the
> boot sequence to set this stuff up before user space starts and leave
> the boot process alone and simple.
> 
> The KISS principle applies here fully.

Ok so the late initcall should work.

Thanks.

-- 
Frederic Weisbecker
SUSE Labs