[PATCH] kunit: irq: Continue increasing hrtimer interval for longer

0 views
Skip to first unread message

Eric Biggers

unread,
Aug 3, 2026, 2:20:58 PM (13 days ago) Aug 3
to linux-...@vger.kernel.org, linux-...@vger.kernel.org, Ard Biesheuvel, Jason A . Donenfeld, Herbert Xu, kuni...@googlegroups.com, Brendan Higgins, David Gow, Rae Moar, Eric Biggers, sta...@vger.kernel.org
Currently, kunit_irq_test_timer_func() stops increasing the hrtimer
interval as soon as some forward progress is made in each of softirq and
task context. Update it to use a more aggressive strategy: increase the
interval as long as the hrtimer is running significantly faster than
either context.

This resolves an occasional hang in the CRC and crypto library tests
under qemu-system-s390x. It was exposed by the change in the default
preemption model on s390 from NONE to LAZY. That seems to have exposed
the issue by allowing some forward progress to be made while the actual
system timer tick is still starved, preventing jiffies from increasing
or the task context from making much progress towards max_iterations.

Fixes: 201ceb94aa1d ("kunit: irq: Ensure timer doesn't fire too frequently")
Cc: sta...@vger.kernel.org
Signed-off-by: Eric Biggers <ebig...@kernel.org>
---

This patch is targeting libcrypto-next

include/kunit/run-in-irq-context.h | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/include/kunit/run-in-irq-context.h b/include/kunit/run-in-irq-context.h
index bfe60d6cf28d..3802b6fb218e 100644
--- a/include/kunit/run-in-irq-context.h
+++ b/include/kunit/run-in-irq-context.h
@@ -38,11 +38,13 @@ static enum hrtimer_restart kunit_irq_test_timer_func(struct hrtimer *timer)
softirq_calls = atomic_read(&state->softirq_func_calls);

/*
- * If the timer is firing too often for the softirq or task to ever have
- * a chance to run, increase the timer interval. This is needed on very
- * slow systems.
+ * If the hrtimer is running much faster than the bh_work or the task,
+ * then it is firing too fast and might be starving those contexts as
+ * well as the actual system timer tick. Increase the interval.
*/
- if (hardirq_calls >= 20 && (softirq_calls == 0 || task_calls == 0))
+ if (hardirq_calls >= 20 &&
+ (hardirq_calls / 2 > softirq_calls ||
+ hardirq_calls / 2 > task_calls))
state->interval = ktime_add_ns(state->interval, 250);

if (!state->func(state->test_specific_state))

base-commit: 6d22ec26295c1412d765e3d687e46224fc332928
--
2.55.0

Ard Biesheuvel

unread,
Aug 4, 2026, 11:39:19 AM (12 days ago) Aug 4
to Eric Biggers, linux-...@vger.kernel.org, linux-...@vger.kernel.org, Jason A . Donenfeld, Herbert Xu, kuni...@googlegroups.com, Brendan Higgins, David Gow, Rae Moar, sta...@vger.kernel.org
Acked-by: Ard Biesheuvel <ar...@kernel.org>

David Gow

unread,
Aug 5, 2026, 9:53:46 AM (11 days ago) Aug 5
to Eric Biggers, linux-...@vger.kernel.org, linux-...@vger.kernel.org, Ard Biesheuvel, Jason A . Donenfeld, Herbert Xu, kuni...@googlegroups.com, Brendan Higgins, Rae Moar, sta...@vger.kernel.org
Le 04/08/2026 à 02:18, Eric Biggers a écrit :
> Currently, kunit_irq_test_timer_func() stops increasing the hrtimer
> interval as soon as some forward progress is made in each of softirq and
> task context. Update it to use a more aggressive strategy: increase the
> interval as long as the hrtimer is running significantly faster than
> either context.
>
> This resolves an occasional hang in the CRC and crypto library tests
> under qemu-system-s390x. It was exposed by the change in the default
> preemption model on s390 from NONE to LAZY. That seems to have exposed
> the issue by allowing some forward progress to be made while the actual
> system timer tick is still starved, preventing jiffies from increasing
> or the task context from making much progress towards max_iterations.
>
> Fixes: 201ceb94aa1d ("kunit: irq: Ensure timer doesn't fire too frequently")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eric Biggers <ebig...@kernel.org>
> ---
>
> This patch is targeting libcrypto-next
>

Thanks. Nothing else is touching this, so taking it through
libcrypto-next is fine.

Reviewed-by: David Gow <da...@davidgow.net>

Cheers,
-- David

Eric Biggers

unread,
Aug 5, 2026, 3:47:56 PM (11 days ago) Aug 5
to linux-...@vger.kernel.org, linux-...@vger.kernel.org, Ard Biesheuvel, Jason A . Donenfeld, Herbert Xu, kuni...@googlegroups.com, Brendan Higgins, David Gow, Rae Moar, sta...@vger.kernel.org
On Mon, Aug 03, 2026 at 11:18:41AM -0700, Eric Biggers wrote:
> Currently, kunit_irq_test_timer_func() stops increasing the hrtimer
> interval as soon as some forward progress is made in each of softirq and
> task context. Update it to use a more aggressive strategy: increase the
> interval as long as the hrtimer is running significantly faster than
> either context.
>
> This resolves an occasional hang in the CRC and crypto library tests
> under qemu-system-s390x. It was exposed by the change in the default
> preemption model on s390 from NONE to LAZY. That seems to have exposed
> the issue by allowing some forward progress to be made while the actual
> system timer tick is still starved, preventing jiffies from increasing
> or the task context from making much progress towards max_iterations.
>
> Fixes: 201ceb94aa1d ("kunit: irq: Ensure timer doesn't fire too frequently")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eric Biggers <ebig...@kernel.org>
> ---
>
> This patch is targeting libcrypto-next

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=libcrypto-next

- Eric
Reply all
Reply to author
Forward
0 new messages