linux-kernel - Re: [RESEND PATCH v13 0/9] 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: <5ee084ed5fea93aced2a3d78ddb480e84b57a68c.camel@redhat.com>
Date: Fri, 31 Oct 2025 15:03:56 +0100
From: Gabriele Monaco <gmonaco@...hat.com>
To: Frederic Weisbecker <frederic@...nel.org>, Waiman Long <llong@...hat.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org, 
 Anna-Maria Behnsen <anna-maria@...utronix.de>
Subject: Re: [RESEND PATCH v13 0/9] timers: Exclude isolated cpus from timer
 migration

On Fri, 2025-10-31 at 14:48 +0100, Frederic Weisbecker wrote:
> Le Thu, Oct 30, 2025 at 01:57:50PM -0400, Waiman Long a écrit :
> > These 2 cpuset patches are actually independent of the timer related
> > changes. The purpose of these two patches are to prevent the cpuset code
> > from adding isolated CPUs in such a way that all the nohz_full HK CPUs
> > become domain-isolated. This is a corner case that normal users won't try to
> > do. The patches are just an insurance policy to ensure that users can't do
> > that. This is complementary to the sched/isolation patch that limits what
> > CPUs can be put to the isolcpus and nohz_full boot parameters. All these
> > patches are independent of the timer related changes, though you can say
> > that the solution will only be complete if all the pieces are in place.
> 
> Right but there will be a conflict if the timer patches don't have
> the rename of update_unbound_workqueue_cpumask().
> 

Waiman, are you referring to [1]?

Since that is an RFC, couldn't you just take in those patches before merging [1]
and adapt just that one directly in the cpuset tree? I guess git should figure
it out if we keep my cpuset patches in both trees (or at least 5/9), as long as
the conflicts come in later commits.
Different story is if you already took some conflicting patches in, then I can
look into rebasing as Frederic suggests.

Thanks,
Gabriele

[1] -
https://lore.kernel.org/lkml/20251025064844.495525-8-chenridong@huaweicloud.com

> > There are another set of pending cpuset patches from Chen Ridong that does
> > some restructuring of the cpuset code that will likely have some conflicts
> > with these 2 patches. So I would like to settle the cpuset changes to avoid
> > future conflicts.
> 
> Ok so it looks like there will be conflicts eventually during the merge
> window. In that case it makes sense to take Gabriel cpuset patches but
> he'll need to rebase the rest on top of the timer tree.
> 
> Thanks.
> 
> > 
> > Cheers,
> > Longman
> >