linux-kernel - Re: [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration

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: <aR5FK-RkGlUv0qY3@pavilion.home>
Date: Wed, 19 Nov 2025 23:31:07 +0100
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>,
	"John B. Wyatt IV" <jwyatt@...hat.com>,
	"John B. Wyatt IV" <sageofredondo@...il.com>
Subject: Re: [PATCH v15 7/7] timers: Exclude isolated cpus from timer
 migration

Le Wed, Nov 19, 2025 at 11:10:58PM +0100, Thomas Gleixner a écrit :
> On Wed, Nov 19 2025 at 23:02, Frederic Weisbecker wrote:
> > Le Wed, Nov 19, 2025 at 10:23:11PM +0100, Thomas Gleixner a écrit :
> >> If you want to be a bit smarter, then you can just use a global mutex,
> >> which is taken inside the set/clear_available() functions which
> >> serializes the related functionality and bulk schedule/flush the unisol
> >> (make available) first and then proceed to the isol (make unavailable).
> >> 
> >> Then nothing has to change vs. the set/clear operations and everything
> >> just works.
> >> 
> >> That mutex does not do any harm in the CPU hotplug case and the
> >> serialization vs. the workers is not going to be the end of the world.
> >> 
> >> I'm willing to bet that no real-world use-case will ever notice the
> >> existance of this mutex. The microbenchmark which shows off the "I'm so
> >> smart" metric is completely irrelevant especially when the result is
> >> fragile, incomprehensible and therefore unmaintainable.
> >> 
> >> Keep it correct and simple is still the most important engineering
> >> principle. Premature optimization is a guaranteed path to failure.
> >> 
> >> If there is a compelling use case which justifies the resulting
> >> complexity, then it can be built on top. I'm not holding my breath. See
> >> above...
> >
> > Perhaps the only thing that worries me is if an isolated partition
> > is inverted. Say 0-3 is non isolated and 4-7 is isolated. And then
> > cpuset is overwritten so that the reverse is applied: 0-3 is isolated
> > and 4-7 is not isolated. If all isol works reach before unisol works,
> > then tmigr_clear_cpu_available() -> cpumask_any(tmigr_available_mask)
> > won't find any CPU left on the last call.
> 
> schedule the newly available (now unisolated) ones first and flush that
> work. After that you can safely mark the others unavailable, no?

Yes!

-- 
Frederic Weisbecker
SUSE Labs