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

[Peter Zijlstra <peterz@infradead.org>]

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.