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

Message-ID: <87cy5dlll9.ffs@tglx>
Date: Wed, 19 Nov 2025 23:10:58 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Frederic Weisbecker <frederic@...nel.org>
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

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?

Thanks

        tglx