Re: [PATCH 6.12 000/144] 6.12.90-rc1 review
From: Peter Schneider
Date: Sat May 16 2026 - 16:20:52 EST
Am 16.05.2026 um 20:09 schrieb Wentao Guan:
Am 16.05.2026 um 12:09 schrieb Greg KH:
On Sat, May 16, 2026 at 03:07:14AM +0800, Wentao Guan wrote:
Build failed, you can drop the commit to build ok, same as 6.18.30-rc1:
git revert 14d9ce90cf4855d638ecbcdb0c208a144d6f991b..
Revert "sched_ext: Use HK_TYPE_DOMAIN_BOOT to detect isolcpus= domain isolation"
Tested-by: Wentao Guan <guanwentao@xxxxxxxxxxxxx>
BRs
Wentao Guan
defconfigs:
https://gist.github.com/opsiff/a840ae9e3d6857f5b7bacb9cdc49f8e9
Log:
In file included from kernel/sched/build_policy.c:63:
kernel/sched/ext.c: In function ‘scx_ops_enable’:
kernel/sched/ext.c:5524:34: error: ‘HK_TYPE_DOMAIN_BOOT’ undeclared (first use in this function); did you mean ‘HK_TYPE_DOMAIN’?
5524 | if (housekeeping_enabled(HK_TYPE_DOMAIN_BOOT)) {
| ^~~~~~~~~~~~~~~~~~~
| HK_TYPE_DOMAIN
missed HK_TYPE_DOMAIN_BOOT is introduced in this commit:
commit 4fca0e550d506e1c95504c2d9247bc92bf621bf6
Author: Frederic Weisbecker <frederic@xxxxxxxxxx>
Date: Mon May 26 13:06:21 2025 +0200
sched/isolation: Save boot defined domain flags
HK_TYPE_DOMAIN will soon integrate not only boot defined isolcpus= CPUs
but also cpuset isolated partitions.
Housekeeping still needs a way to record what was initially passed
to isolcpus= in order to keep these CPUs isolated after a cpuset
isolated partition is modified or destroyed while containing some of
them.
Create a new HK_TYPE_DOMAIN_BOOT to keep track of those.
Signed-off-by: Frederic Weisbecker <frederic@xxxxxxxxxx>
Reviewed-by: Phil Auld <pauld@xxxxxxxxxx>
Reviewed-by: Waiman Long <longman@xxxxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxxxxx>
Cc: Marco Crivellari <marco.crivellari@xxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxx>
Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Cc: Tejun Heo <tj@xxxxxxxxxx>
Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Cc: Vlastimil Babka <vbabka@xxxxxxx>
Cc: Waiman Long <longman@xxxxxxxxxx>
Also dropped from here, thanks. My fault, I should have only backported
this to 7.0.y as the commit itself said to.
greg k-h
Now I really wonder why I didn't hit this build error with that patch included in 6.12.90-rc1...
Because I hit it in 6.18.32-rc!
Let me check my .config ...
Beste Grüße,
Peter Schneider
Hello,
I thought that 'CONFIG_SCHED_CLASS_EXT' is what you found,
and it is depends include 'DEBUG_INFO_BTF' which depend pahole (maybe missed).
BRs
Wentao Guan
Yes, you are absolutely right!
I do all my tests on one of my Proxmox maschines which by default run some x.y.z-pve Kernel, and I always use the .config of the closest PVE kernel as template for the .config of the kernel I want to test.
So for 6.12.90-rc1 I copied config-6.11.11-2-pve and did a "make olddefconfig", and 6.11 did not have CONFIG_SCHED_CLASS_EXT yet at all, so I ended up testing with CONFIG_SCHED_CLASS_EXT not set.
While for 6.18.32-rc1, I copied config-6.17.13-9-pve and did "make olddefconfig", and 6.17 already had that functionality (I guess since mainline 6.12), and so for that version, I had CONFIG_SCHED_CLASS_EXT=y
Beste Grüße,
Peter Schneider
--
Climb the mountain not to plant your flag, but to embrace the challenge,
enjoy the air and behold the view. Climb it so you can see the world,
not so the world can see you. -- David McCullough Jr.
OpenPGP: 0xA3828BD796CCE11A8CADE8866E3A92C92C3FF244
Download: https://www.peters-netzplatz.de/download/pschneider1968_pub.asc
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@xxxxxxxxxxxxxx
https://keys.mailvelope.com/pks/lookup?op=get&search=pschneider1968@xxxxxxxxx