linux-kernel - Re: [PATCH v11 8/8] 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: <a95a06743850f85b46dca5f8d1181e73ed70519c.camel@redhat.com>
Date: Mon, 08 Sep 2025 10:35:22 +0200
From: Gabriele Monaco <gmonaco@...hat.com>
To: Frederic Weisbecker <frederic@...nel.org>, Waiman Long
 <longman@...hat.com>
Cc: linux-kernel@...r.kernel.org, Anna-Maria Behnsen
 <anna-maria@...utronix.de>,  Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v11 8/8] timers: Exclude isolated cpus from timer
 migration

On Tue, 2025-09-02 at 14:45 +0200, Frederic Weisbecker wrote:
> > On Mon, 2025-09-01 at 23:11 +0200, Frederic Weisbecker wrote:
> > > Right, Thomas didn't like it, but the organization of the code
> > > has changed a bit since then with the late initcall. If the best
> > > we can do to workaround the situation is to make the CPU
> > > unavailable regardless and then undo that right after with an
> > > IPI, then it's a good sign that we should just simplify and
> > > eventually check tick_nohz_cpu_hotpluggable() from
> > > tmigr_is_isolated().
> > Here I'm a bit unsure how to proceed though. We want to fail any
> > single isolated cpuset that includes the tick CPU under nohz_full.
> > I can do it directly in isolcpus_nohz_conflict and that looks easy.
> > 
> > But is that going to be clear for the user?
> > Can the user even know what the tick CPU is? Besides /assuming/ 0.
> 
> You're right the user can't know in advance which CPU is the tick.
> I don't mind if we prevent or not cpuset from allowing to isolate
> the timekeeper but either way, a pr_info() could be helpful to tell
> that either:
> 
> * The isolated timekeeper will have limited isolation
> or
> * The timekeeper can't be isolated.
> 

As far as I understand, we are now decided to fail cpuset isolated
assignments involving the tick CPU when nohz_full is active.

What prevents us from doing the same in the isolcpus code?
Or at least un-isolate the tick cpu like it happens for nohz_full?

The patch currently avoids the tick CPU in the isolated tmigr logic but
allows it anywhere else.
I believe if we are changing this, cpusets and isolcpus should at least
be consistent.

I remember I went down this path because it was mentioned the tick CPU
is allowed to change. Is this really a concern when nohz_full is
active?

If the tick CPU can change after boot, we would probably need to track
this change either way (in tmigr or isolation/cpuset), but it doesn't
seem the case to me.

If we guarantee the tick cpu is never isolated, we can get rid of the
tick_nohz_cpu_hotpluggable() check for good.

Am I missing anything?

Thanks,
Gabriele