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@uniontech.com
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@kernel.org 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@kernel.org> Reviewed-by: Phil Auld <pauld@redhat.com> Reviewed-by: Waiman Long <longman@redhat.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Marco Crivellari <marco.crivellari@suse.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Tejun Heo <tj@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vlastimil Babka <vbabka@suse.cz> Cc: Waiman Long <longman@redhat.com>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