From: Peter Zijlstra <peterz@infradead.org>
To: Sean Christopherson <seanjc@google.com>
Cc: kernel test robot <oliver.sang@intel.com>,
oe-lkp@lists.linux.dev, lkp@intel.com,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
sched-ext@lists.linux.dev, aubrey.li@linux.intel.com,
yu.c.chen@intel.com
Subject: Re: [linus:master] [sched/core] 704069649b: kernel-selftests.kvm.hardware_disable_test.fail
Date: Wed, 18 Feb 2026 17:33:29 +0100 [thread overview]
Message-ID: <20260218163329.GQ1395416@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20260218094053.GD2995752@noisy.programming.kicks-ass.net>
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);
next prev parent reply other threads:[~2026-02-18 16:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-12 14:08 kernel test robot
2026-02-13 10:40 ` Peter Zijlstra
2026-02-13 22:06 ` Sean Christopherson
2026-02-13 14:44 ` Peter Zijlstra
2026-02-13 22:14 ` Sean Christopherson
2026-02-18 9:40 ` Peter Zijlstra
2026-02-18 16:33 ` Peter Zijlstra [this message]
2026-02-23 10:25 ` [tip: sched/urgent] sched/core: Fix wakeup_preempt's next_class tracking tip-bot2 for Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260218163329.GQ1395416@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=aubrey.li@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=mingo@kernel.org \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=sched-ext@lists.linux.dev \
--cc=seanjc@google.com \
--cc=yu.c.chen@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome