[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3e8e9510-3d05-4a31-a4de-30c97f70826d@paulmck-laptop>
Date: Fri, 19 Dec 2025 21:01:39 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
linux-next@...r.kernel.org, Stephen Rothwell <sfr@...b.auug.org.au>,
Mark Brown <broonie@...nel.org>, kernel-team@...a.com
Subject: Re: Shutdown-time hangs in -next in locktorture
On Fri, Dec 19, 2025 at 04:29:27PM -0800, Paul E. McKenney wrote:
> Hello, Peter,
>
> I started hitting shutdown-time hangs in next-20251217 which persist
> in next-20251219. This hang happens on both x86 and arm64. Once I
> figured out that the failure is high probability, but not deterministic,
> bisection converged here:
>
> 5d1f0b2f278e ("sched/core: Rework sched_class::wakeup_preempt() and rq_modified_*()")
>
> This commit reverts cleanly, and doing so restores hang-free operation.
>
> The reproducer is shown below.
>
> Thoughts?
With Chris Mason's help, I checked with a friendly local LLM, which
noted that a call to rq_modified_above() remains in kernel/sched/ext.c
in function do_pick_task_scx(). Of course, that does not explain a
locktorture hang, especially given that locktorture does not build
that file. But in case it is helpful.
Thanx, Paul
> ------------------------------------------------------------------------
>
> for i in 1 2 3 4 5
> do
> tools/testing/selftests/rcutorture/bin/torture.sh --duration 20 --do-none --do-normal --do-locktorture --do-kasan --configs-locktorture "LOCK09"
> ret=$?
> if test "$ret" -ne 0
> then
> exit "$ret"
> fi
> echo Test $i succeeded
> done
> exit 0
Powered by blists - more mailing lists