linux-kernel - Re: [PATCH] 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: <Z_fkgN1ro9AeM1QY@localhost.localdomain>
Date: Thu, 10 Apr 2025 17:32:16 +0200
From: Frederic Weisbecker <frederic@...nel.org>
To: Gabriele Monaco <gmonaco@...hat.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
	Waiman Long <longman@...hat.com>
Subject: Re: [PATCH] timers: Exclude isolated cpus from timer migation

Le Thu, Apr 10, 2025 at 05:05:52PM +0200, Gabriele Monaco a écrit :
> I'm not understanding what is going to be invasive in this case.
> Aren't we just talking about not allowing isolcpus to pull timers from
> other cpus?

Right, but in order to do that you need to avoid remotely executing
timers. And for that we need your initial patch (after reviews have
been addressed). Right?

> Let's ignore for now the global timers started on those CPUs, I'm not
> aware of complaints regarding that.
> 
> As far as I understand, the change would allow timer migration to work
> normally out of isolcpus and among housekeeping ones, we are not
> forcing any migration that would potentially introduce overhead or
> missed timers.
> Or am I oversimplifying it?

Global timers only migrate:

a) When a CPU goes offline (but they should be migrated to
  a housekeeping CPU)

b) When a timer executes remotely and re-enqueues itself.

In order to handle b), you must make sure an isolated CPU
can't execute timers remotely. Hence why it must be set
as not available like you did.

Or am I missing something else?

Thanks.

-- 
Frederic Weisbecker
SUSE Labs