[linus:master] [sched/core] 704069649b: kernel-selftests.kvm.hardware_disable_test.fail

[linus:master] [sched/core] 704069649b: kernel-selftests.kvm.hardware_disable_test.fail

[kernel test robot]

Hello,

we found the kernel-selftests.kvm.hardware_disable_test failed consistently upon
this commit but pass on parent. unfortunately, we didn't find many useful
information in dmesg. this report is just FYI what we observed in our tests.



kernel test robot noticed "kernel-selftests.kvm.hardware_disable_test.fail" on:

commit: 704069649b5bfb7bf1fe32c0281fe9036806a59a ("sched/core: Rework sched_class::wakeup_preempt() and rq_modified_*()")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master


in testcase: kernel-selftests
version: kernel-selftests-x86_64-05f7e89ab973-1_20260208
with following parameters:

	group: kvm



config: x86_64-rhel-9.4-kselftests
compiler: gcc-14
test machine: 224 threads 2 sockets Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids) with 256G memory

(please refer to attached dmesg/kmsg for entire log/backtrace)


If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202602122157.4e861298-lkp@intel.com



# timeout set to 120
# selftests: kvm: hardware_disable_test
# Random seed: 0x6b8b4567
#
not ok 85 selftests: kvm: hardware_disable_test # TIMEOUT 120 seconds
/bin/sh: 50: cannot create : Directory nonexistent



The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20260212/202602122157.4e861298-lkp@intel.com



-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [linus:master] [sched/core] 704069649b: kernel-selftests.kvm.hardware_disable_test.fail

[Peter Zijlstra]

On Thu, Feb 12, 2026 at 10:08:04PM +0800, kernel test robot wrote:
> 
> 
> Hello,
> 
> we found the kernel-selftests.kvm.hardware_disable_test failed consistently upon
> this commit but pass on parent. unfortunately, we didn't find many useful
> information in dmesg. this report is just FYI what we observed in our tests.
> 
> 
> 
> kernel test robot noticed "kernel-selftests.kvm.hardware_disable_test.fail" on:
> 
> commit: 704069649b5bfb7bf1fe32c0281fe9036806a59a ("sched/core: Rework sched_class::wakeup_preempt() and rq_modified_*()")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> 
> 

So this commit has been in tip (and thus -next) since 17 Dev '25. How
come this is only reported now?

Anyway, let me see if I can manage to build the kvm selftests today
(last time I tried it was an utter trainwreck).

Re: [linus:master] [sched/core] 704069649b: kernel-selftests.kvm.hardware_disable_test.fail

[Sean Christopherson]

On Fri, Feb 13, 2026, Peter Zijlstra wrote:
> On Thu, Feb 12, 2026 at 10:08:04PM +0800, kernel test robot wrote:
> > we found the kernel-selftests.kvm.hardware_disable_test failed consistently upon
> > this commit but pass on parent. unfortunately, we didn't find many useful
> > information in dmesg. this report is just FYI what we observed in our tests.
> > 
> > kernel test robot noticed "kernel-selftests.kvm.hardware_disable_test.fail" on:
> > 
> > commit: 704069649b5bfb7bf1fe32c0281fe9036806a59a ("sched/core: Rework sched_class::wakeup_preempt() and rq_modified_*()")
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> 
> So this commit has been in tip (and thus -next) since 17 Dev '25. How
> come this is only reported now?

Well, on my end, I still don't do a good job of testing linux-next.  But AFAICT,
it wouldn't have mattered in this case, because I probably wouldn't have noticed
given the nature of the failure and how I run KVM selftests.

Re: [linus:master] [sched/core] 704069649b: kernel-selftests.kvm.hardware_disable_test.fail

[Peter Zijlstra]

On Thu, Feb 12, 2026 at 10:08:04PM +0800, kernel test robot wrote:
> 
> 
> Hello,
> 
> we found the kernel-selftests.kvm.hardware_disable_test failed consistently upon
> this commit but pass on parent. unfortunately, we didn't find many useful
> information in dmesg. this report is just FYI what we observed in our tests.
> 
> 
> 
> kernel test robot noticed "kernel-selftests.kvm.hardware_disable_test.fail" on:

With the caveat of PEBKAC (it is Friday after all); I can't reproduce.

That is, ./hardware_disable_test as build from cee73b1e840c, doesn't
work for me on 704069649b5b^1 either.

Sean; is there a magic trick to operating that test, or is it a known
trouble spot?

> 
> commit: 704069649b5bfb7bf1fe32c0281fe9036806a59a ("sched/core: Rework sched_class::wakeup_preempt() and rq_modified_*()")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> 
> 
> in testcase: kernel-selftests
> version: kernel-selftests-x86_64-05f7e89ab973-1_20260208
> with following parameters:
> 
> 	group: kvm
> 
> 
> 
> config: x86_64-rhel-9.4-kselftests
> compiler: gcc-14
> test machine: 224 threads 2 sockets Intel(R) Xeon(R) Platinum 8480+ (Sapphire Rapids) with 256G memory
> 
> (please refer to attached dmesg/kmsg for entire log/backtrace)
> 
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <oliver.sang@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202602122157.4e861298-lkp@intel.com
> 
> 
> 
> # timeout set to 120
> # selftests: kvm: hardware_disable_test
> # Random seed: 0x6b8b4567
> #
> not ok 85 selftests: kvm: hardware_disable_test # TIMEOUT 120 seconds
> /bin/sh: 50: cannot create : Directory nonexistent
> 
> 
> 
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20260212/202602122157.4e861298-lkp@intel.com
> 
> 
> 
> -- 
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
> 

Re: [linus:master] [sched/core] 704069649b: kernel-selftests.kvm.hardware_disable_test.fail

[Sean Christopherson]

On Fri, Feb 13, 2026, Peter Zijlstra wrote:
> On Thu, Feb 12, 2026 at 10:08:04PM +0800, kernel test robot wrote:
> > Hello,
> > 
> > we found the kernel-selftests.kvm.hardware_disable_test failed consistently upon
> > this commit but pass on parent. unfortunately, we didn't find many useful
> > information in dmesg. this report is just FYI what we observed in our tests.
> > 
> > kernel test robot noticed "kernel-selftests.kvm.hardware_disable_test.fail" on:
> 
> With the caveat of PEBKAC (it is Friday after all); I can't reproduce.
> 
> That is, ./hardware_disable_test as build from cee73b1e840c, doesn't
> work for me on 704069649b5b^1 either.
> 
> Sean; is there a magic trick to operating that test, or is it a known
> trouble spot?

Hmm, shouldn't require any magic, and hasn't been known to be flaky.

This very decisively points at 704069649b5b ("sched/core: Rework
sched_class::wakeup_preempt() and rq_modified_*()"). on my end as well.  With
that commit reverted, the below runs in ~40ms total.  With 704069649b5b present,
the test constantly stalls for multiple seconds at sem_timedwait().

AFAICT, the key is to have the busy_loop() pthread affined to the same CPU as
its parent.  The KVM pieces of the selftest have nothing to do with the failure.

Here's a minimal reproducer that you can build without selftests goo :-)
E.g. `gcc -pthread -o busy busy.c` should work.

// SPDX-License-Identifier: GPL-2.0-only
#define _GNU_SOURCE

#include <fcntl.h>
#include <pthread.h>
#include <sched.h>
#include <semaphore.h>
#include <stdint.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/wait.h>
#include <unistd.h>

sem_t *sem;

static void *busy_loop(void *arg)
{
	for (;;)
		;

	return NULL;
}

static void run_test(uint32_t run)
{
	pthread_t thread;
	cpu_set_t cpuset;

	CPU_ZERO(&cpuset);
	CPU_SET(sched_getcpu(), &cpuset);

	printf("%s: [%d] spawn busy thread\n", __func__, run);
	if (pthread_create(&thread, NULL, busy_loop, (void *)NULL))
		exit(-1);

	if (pthread_setaffinity_np(thread, sizeof(cpuset), &cpuset))
		exit(-1);

	printf("%s: [%d] thread launched\n", __func__, run);
	sem_post(sem);

	pthread_join(thread, NULL);
	printf("child pthread exited prematurely\n");
	exit(-1);
}

void wait_for_child_setup(pid_t pid)
{
	/*
	 * Wait for the child to post to the semaphore, but wake up periodically
	 * to check if the child exited prematurely.
	 */
	for (;;) {
		const struct timespec wait_period = { .tv_sec = 1 };
		int status;

		if (!sem_timedwait(sem, &wait_period))
			return;

		/* Child is still running, keep waiting. */
		if (pid != waitpid(pid, &status, WNOHANG))
			continue;

		/*
		 * Child is no longer running, which is not expected.
		 *
		 * If it exited with a non-zero status, we explicitly forward
		 * the child's status in case it exited with KSFT_SKIP.
		 */
		if (WIFEXITED(status))
			exit(WEXITSTATUS(status));

		printf("Child exited unexpectedly\n");
		exit(-1);
	}
}

int main(int argc, char **argv)
{
	uint32_t i;
	int s, r;
	pid_t pid;

	sem = sem_open("vm_sem", O_CREAT | O_EXCL, 0644, 0);
	sem_unlink("vm_sem");

	for (i = 0; i < 512; ++i) {
		pid = fork();
		if (pid < 0)
			exit(-1);
		if (pid == 0)
			run_test(i); /* This function always exits */

		printf("%s: [%d] waiting semaphore\n", __func__, i);
		wait_for_child_setup(pid);

		printf("%s: [%d] do waitpid\n", __func__, i);
		r = waitpid(pid, &s, WNOHANG);
		if (r == pid) {
			printf("%s: [%d] child exited unexpectedly status: [%d]",
			       __func__, i, s);
			exit(-1);
		}
		printf("%s: [%d] killing child\n", __func__, i);
		kill(pid, SIGKILL);
	}

	sem_destroy(sem);
	exit(0);
}

Re: [linus:master] [sched/core] 704069649b: kernel-selftests.kvm.hardware_disable_test.fail

[Peter Zijlstra]

On Fri, Feb 13, 2026 at 02:14:14PM -0800, Sean Christopherson wrote:
> On Fri, Feb 13, 2026, Peter Zijlstra wrote:
> > On Thu, Feb 12, 2026 at 10:08:04PM +0800, kernel test robot wrote:
> > > Hello,
> > > 
> > > we found the kernel-selftests.kvm.hardware_disable_test failed consistently upon
> > > this commit but pass on parent. unfortunately, we didn't find many useful
> > > information in dmesg. this report is just FYI what we observed in our tests.
> > > 
> > > kernel test robot noticed "kernel-selftests.kvm.hardware_disable_test.fail" on:
> > 
> > With the caveat of PEBKAC (it is Friday after all); I can't reproduce.

PEBCAK indeed, I managed to consistently boot into the bad kernel :-(
So never actually tested the good one.

> > That is, ./hardware_disable_test as build from cee73b1e840c, doesn't
> > work for me on 704069649b5b^1 either.
> > 
> > Sean; is there a magic trick to operating that test, or is it a known
> > trouble spot?
> 
> Hmm, shouldn't require any magic, and hasn't been known to be flaky.
> 
> This very decisively points at 704069649b5b ("sched/core: Rework
> sched_class::wakeup_preempt() and rq_modified_*()"). on my end as well.  With
> that commit reverted, the below runs in ~40ms total.  With 704069649b5b present,
> the test constantly stalls for multiple seconds at sem_timedwait().
> 
> AFAICT, the key is to have the busy_loop() pthread affined to the same CPU as
> its parent.  The KVM pieces of the selftest have nothing to do with the failure.
> 
> Here's a minimal reproducer that you can build without selftests goo :-)
> E.g. `gcc -pthread -o busy busy.c` should work.

Whee, thanks! OK, let me go prod at this with something sharp, see what
falls out.

Re: [linus:master] [sched/core] 704069649b: kernel-selftests.kvm.hardware_disable_test.fail

[Peter Zijlstra]

On Wed, Feb 18, 2026 at 10:40:53AM +0100, Peter Zijlstra wrote:
> On Fri, Feb 13, 2026 at 02:14:14PM -0800, Sean Christopherson wrote:
> > On Fri, Feb 13, 2026, Peter Zijlstra wrote:
> > > On Thu, Feb 12, 2026 at 10:08:04PM +0800, kernel test robot wrote:
> > > > Hello,
> > > > 
> > > > we found the kernel-selftests.kvm.hardware_disable_test failed consistently upon
> > > > this commit but pass on parent. unfortunately, we didn't find many useful
> > > > information in dmesg. this report is just FYI what we observed in our tests.
> > > > 
> > > > kernel test robot noticed "kernel-selftests.kvm.hardware_disable_test.fail" on:
> > > 
> > > With the caveat of PEBKAC (it is Friday after all); I can't reproduce.
> 
> PEBCAK indeed, I managed to consistently boot into the bad kernel :-(
> So never actually tested the good one.
> 
> > > That is, ./hardware_disable_test as build from cee73b1e840c, doesn't
> > > work for me on 704069649b5b^1 either.
> > > 
> > > Sean; is there a magic trick to operating that test, or is it a known
> > > trouble spot?
> > 
> > Hmm, shouldn't require any magic, and hasn't been known to be flaky.
> > 
> > This very decisively points at 704069649b5b ("sched/core: Rework
> > sched_class::wakeup_preempt() and rq_modified_*()"). on my end as well.  With
> > that commit reverted, the below runs in ~40ms total.  With 704069649b5b present,
> > the test constantly stalls for multiple seconds at sem_timedwait().
> > 
> > AFAICT, the key is to have the busy_loop() pthread affined to the same CPU as
> > its parent.  The KVM pieces of the selftest have nothing to do with the failure.
> > 
> > Here's a minimal reproducer that you can build without selftests goo :-)
> > E.g. `gcc -pthread -o busy busy.c` should work.
> 
> Whee, thanks! OK, let me go prod at this with something sharp, see what
> falls out.

This seems to work. I'll go write a Changelog after dinner.

---
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 759777694c78..b7f77c165a6e 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6830,6 +6830,7 @@ static void __sched notrace __schedule(int sched_mode)
 		/* SCX must consult the BPF scheduler to tell if rq is empty */
 		if (!rq->nr_running && !scx_enabled()) {
 			next = prev;
+			rq->next_class = &idle_sched_class;
 			goto picked;
 		}
 	} else if (!preempt && prev_state) {
diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
index c18e81e8ef51..3afa96d5d1ba 100644
--- a/kernel/sched/ext.c
+++ b/kernel/sched/ext.c
@@ -2460,7 +2460,7 @@ do_pick_task_scx(struct rq *rq, struct rq_flags *rf, bool force_scx)
 	/* see kick_cpus_irq_workfn() */
 	smp_store_release(&rq->scx.kick_sync, rq->scx.kick_sync + 1);
 
-	rq->next_class = &ext_sched_class;
+	rq_modified_begin(rq, &ext_sched_class);
 
 	rq_unpin_lock(rq, rf);
 	balance_one(rq, prev);
@@ -2475,7 +2475,7 @@ do_pick_task_scx(struct rq *rq, struct rq_flags *rf, bool force_scx)
 	 * If @force_scx is true, always try to pick a SCHED_EXT task,
 	 * regardless of any higher-priority sched classes activity.
 	 */
-	if (!force_scx && sched_class_above(rq->next_class, &ext_sched_class))
+	if (!force_scx && rq_modified_above(rq, &ext_sched_class))
 		return RETRY_TASK;
 
 	keep_prev = rq->scx.flags & SCX_RQ_BAL_KEEP;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 1e22b7fadd70..8e5864ec4cf9 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -12908,7 +12908,7 @@ static int sched_balance_newidle(struct rq *this_rq, struct rq_flags *rf)
 	t0 = sched_clock_cpu(this_cpu);
 	__sched_balance_update_blocked_averages(this_rq);
 
-	this_rq->next_class = &fair_sched_class;
+	rq_modified_begin(this_rq, &fair_sched_class);
 	raw_spin_rq_unlock(this_rq);
 
 	for_each_domain(this_cpu, sd) {
@@ -12975,7 +12975,7 @@ static int sched_balance_newidle(struct rq *this_rq, struct rq_flags *rf)
 		pulled_task = 1;
 
 	/* If a higher prio class was modified, restart the pick */
-	if (sched_class_above(this_rq->next_class, &fair_sched_class))
+	if (rq_modified_above(this_rq, &fair_sched_class))
 		pulled_task = -1;
 
 out:
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index b82fb70a9d54..43bbf0693cca 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2748,6 +2748,17 @@ static inline const struct sched_class *next_active_class(const struct sched_cla
 
 #define sched_class_above(_a, _b)	((_a) < (_b))
 
+static inline void rq_modified_begin(struct rq *rq, const struct sched_class *class)
+{
+	if (sched_class_above(rq->next_class, class))
+		rq->next_class = class;
+}
+
+static inline bool rq_modified_above(struct rq *rq, const struct sched_class *class)
+{
+	return sched_class_above(rq->next_class, class);
+}
+
 static inline bool sched_stop_runnable(struct rq *rq)
 {
 	return rq->stop && task_on_rq_queued(rq->stop);

[tip: sched/urgent] sched/core: Fix wakeup_preempt's next_class tracking

[tip-bot2 for Peter Zijlstra]

The following commit has been merged into the sched/urgent branch of tip:

Commit-ID:     5324953c06bd929c135d9e04be391ee2c11b5a19
Gitweb:        https://git.kernel.org/tip/5324953c06bd929c135d9e04be391ee2c11b5a19
Author:        Peter Zijlstra <peterz@infradead.org>
AuthorDate:    Wed, 18 Feb 2026 17:33:29 +01:00
Committer:     Peter Zijlstra <peterz@infradead.org>
CommitterDate: Mon, 23 Feb 2026 11:19:19 +01:00

sched/core: Fix wakeup_preempt's next_class tracking

Kernel test robot reported that
tools/testing/selftests/kvm/hardware_disable_test was failing due to
commit 704069649b5b ("sched/core: Rework sched_class::wakeup_preempt()
and rq_modified_*()")

It turns out there were two related problems that could lead to a
missed preemption:

 - when hitting newidle balance from the idle thread, it would elevate
   rb->next_class from &idle_sched_class to &fair_sched_class, causing
   later wakeup_preempt() calls to not hit the sched_class_above()
   case, and not issue resched_curr().

   Notably, this modification pattern should only lower the
   next_class, and never raise it. Create two new helper functions to
   wrap this.

 - when doing schedule_idle(), it was possible to miss (re)setting
   rq->next_class to &idle_sched_class, leading to the very same
   problem.

Cc: Sean Christopherson <seanjc@google.com>
Fixes: 704069649b5b ("sched/core: Rework sched_class::wakeup_preempt() and rq_modified_*()")
Reported-by: kernel test robot <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202602122157.4e861298-lkp@intel.com
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://patch.msgid.link/20260218163329.GQ1395416@noisy.programming.kicks-ass.net
---
 kernel/sched/core.c  |  1 +
 kernel/sched/ext.c   |  4 ++--
 kernel/sched/fair.c  |  4 ++--
 kernel/sched/sched.h | 11 +++++++++++
 4 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 7597776..b7f77c1 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -6830,6 +6830,7 @@ static void __sched notrace __schedule(int sched_mode)
 		/* SCX must consult the BPF scheduler to tell if rq is empty */
 		if (!rq->nr_running && !scx_enabled()) {
 			next = prev;
+			rq->next_class = &idle_sched_class;
 			goto picked;
 		}
 	} else if (!preempt && prev_state) {
diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
index 62b1f3a..06cc0a4 100644
--- a/kernel/sched/ext.c
+++ b/kernel/sched/ext.c
@@ -2460,7 +2460,7 @@ do_pick_task_scx(struct rq *rq, struct rq_flags *rf, bool force_scx)
 	/* see kick_cpus_irq_workfn() */
 	smp_store_release(&rq->scx.kick_sync, rq->scx.kick_sync + 1);
 
-	rq->next_class = &ext_sched_class;
+	rq_modified_begin(rq, &ext_sched_class);
 
 	rq_unpin_lock(rq, rf);
 	balance_one(rq, prev);
@@ -2475,7 +2475,7 @@ do_pick_task_scx(struct rq *rq, struct rq_flags *rf, bool force_scx)
 	 * If @force_scx is true, always try to pick a SCHED_EXT task,
 	 * regardless of any higher-priority sched classes activity.
 	 */
-	if (!force_scx && sched_class_above(rq->next_class, &ext_sched_class))
+	if (!force_scx && rq_modified_above(rq, &ext_sched_class))
 		return RETRY_TASK;
 
 	keep_prev = rq->scx.flags & SCX_RQ_BAL_KEEP;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index f4446cb..bf948db 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -12982,7 +12982,7 @@ static int sched_balance_newidle(struct rq *this_rq, struct rq_flags *rf)
 	t0 = sched_clock_cpu(this_cpu);
 	__sched_balance_update_blocked_averages(this_rq);
 
-	this_rq->next_class = &fair_sched_class;
+	rq_modified_begin(this_rq, &fair_sched_class);
 	raw_spin_rq_unlock(this_rq);
 
 	for_each_domain(this_cpu, sd) {
@@ -13049,7 +13049,7 @@ static int sched_balance_newidle(struct rq *this_rq, struct rq_flags *rf)
 		pulled_task = 1;
 
 	/* If a higher prio class was modified, restart the pick */
-	if (sched_class_above(this_rq->next_class, &fair_sched_class))
+	if (rq_modified_above(this_rq, &fair_sched_class))
 		pulled_task = -1;
 
 out:
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index b82fb70..43bbf06 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2748,6 +2748,17 @@ static inline const struct sched_class *next_active_class(const struct sched_cla
 
 #define sched_class_above(_a, _b)	((_a) < (_b))
 
+static inline void rq_modified_begin(struct rq *rq, const struct sched_class *class)
+{
+	if (sched_class_above(rq->next_class, class))
+		rq->next_class = class;
+}
+
+static inline bool rq_modified_above(struct rq *rq, const struct sched_class *class)
+{
+	return sched_class_above(rq->next_class, class);
+}
+
 static inline bool sched_stop_runnable(struct rq *rq)
 {
 	return rq->stop && task_on_rq_queued(rq->stop);