netdev - Re: [PATCH 29/33] sched/arm64: Move fallback task cpumask to HK_TYPE

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: <aXIKDduX5qUXvOUX@localhost.localdomain>
Date: Thu, 22 Jan 2026 12:29:17 +0100
From: Frederic Weisbecker <frederic@...nel.org>
To: Will Deacon <will@...nel.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
	Michal Koutný <mkoutny@...e.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Chen Ridong <chenridong@...wei.com>,
	Danilo Krummrich <dakr@...nel.org>,
	"David S . Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Gabriele Monaco <gmonaco@...hat.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Ingo Molnar <mingo@...hat.com>, Jakub Kicinski <kuba@...nel.org>,
	Jens Axboe <axboe@...nel.dk>, Johannes Weiner <hannes@...xchg.org>,
	Lai Jiangshan <jiangshanlai@...il.com>,
	Marco Crivellari <marco.crivellari@...e.com>,
	Michal Hocko <mhocko@...e.com>, Muchun Song <muchun.song@...ux.dev>,
	Paolo Abeni <pabeni@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>, Phil Auld <pauld@...hat.com>,
	"Rafael J . Wysocki" <rafael@...nel.org>,
	Roman Gushchin <roman.gushchin@...ux.dev>,
	Shakeel Butt <shakeel.butt@...ux.dev>,
	Simon Horman <horms@...nel.org>, Tejun Heo <tj@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Vlastimil Babka <vbabka@...e.cz>, Waiman Long <longman@...hat.com>,
	cgroups@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-block@...r.kernel.org, linux-mm@...ck.org,
	linux-pci@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 29/33] sched/arm64: Move fallback task cpumask to
 HK_TYPE_DOMAIN

Le Thu, Jan 22, 2026 at 09:56:29AM +0000, Will Deacon a écrit :
> On Wed, Jan 21, 2026 at 06:06:07PM +0100, Frederic Weisbecker wrote:
> > Le Tue, Jan 20, 2026 at 03:15:14PM +0000, Will Deacon a écrit :
> > > Hi Frederic,
> > > 
> > > On Thu, Jan 01, 2026 at 11:13:54PM +0100, Frederic Weisbecker wrote:
> > > > When none of the allowed CPUs of a task are online, it gets migrated
> > > > to the fallback cpumask which is all the non nohz_full CPUs.
> > > > 
> > > > However just like nohz_full CPUs, domain isolated CPUs don't want to be
> > > > disturbed by tasks that have lost their CPU affinities.
> > > > 
> > > > And since nohz_full rely on domain isolation to work correctly, the
> > > > housekeeping mask of domain isolated CPUs should always be a superset of
> > > > the housekeeping mask of nohz_full CPUs (there can be CPUs that are
> > > > domain isolated but not nohz_full, OTOH there shouldn't be nohz_full
> > > > CPUs that are not domain isolated):
> > > > 
> > > > 	HK_TYPE_DOMAIN | HK_TYPE_KERNEL_NOISE == HK_TYPE_DOMAIN
> > > > 
> > > > Therefore use HK_TYPE_DOMAIN as the appropriate fallback target for
> > > > tasks and since this cpumask can be modified at runtime, make sure
> > > > that 32 bits support CPUs on ARM64 mismatched systems are not isolated
> > > > by cpusets.
> > > > 
> > > > Signed-off-by: Frederic Weisbecker <frederic@...nel.org>
> > > > Reviewed-by: Waiman Long <longman@...hat.com>
> > > > ---
> > > >  arch/arm64/kernel/cpufeature.c | 18 +++++++++++++++---
> > > >  include/linux/cpu.h            |  4 ++++
> > > >  kernel/cgroup/cpuset.c         | 17 ++++++++++++++---
> > > >  3 files changed, 33 insertions(+), 6 deletions(-)
> > > 
> > > tbh, I'd also be fine just saying that isolation isn't reliable on these
> > > systems and then you don't need to add the extra arch hook.
> > 
> > Hmm, I think I heard about nohz_full usage on arm64 but I'm not sure.
> > And I usually expect isolcpus or cpuset isolated partitions to be even
> > more broadly used, it's lighter isolation with less constraints.
> > 
> > Anyway you're probably right that we could remove isolation support here
> > but I don't want to break any existing user.
> 
> fwiw, I think it's only some Android markets using the mismatched 32-bit
> support and we're definitely not using nohz_full there.

Now that removal becomes appealing. And what about isolcpus= / isolated cpuset
which only consist in scheduler domain isolation? Probably not used by android
either.

Ok but is there a way to detect on early boot that the system has mismatched
32 bits support? Because I need to fail nohz_full= and isolcpus= boot parameters
early on top of this information without waiting for secondary CPUs boot.

Thanks.

-- 
Frederic Weisbecker
SUSE Labs