lib/crypto/tests/polyval_kunit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
On my development machine the generic, memcpy()-only implementation of
polyval_preparekey() is too fast for the IRQ workers to actually fire.
The test fails.
Increase the iterations to make the test more robust.
The test will run for a maximum of one second in any case.
Fixes: b3aed551b3fc ("lib/crypto: tests: Add KUnit tests for POLYVAL")
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
lib/crypto/tests/polyval_kunit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/crypto/tests/polyval_kunit.c b/lib/crypto/tests/polyval_kunit.c
index e59f598c1572..f47f41a39a41 100644
--- a/lib/crypto/tests/polyval_kunit.c
+++ b/lib/crypto/tests/polyval_kunit.c
@@ -183,7 +183,7 @@ static void test_polyval_preparekey_in_irqs(struct kunit *test)
rand_bytes(state.raw_key, sizeof(state.raw_key));
polyval_preparekey(&state.expected_key, state.raw_key);
- kunit_run_irq_test(test, polyval_irq_test_func, 20000, &state);
+ kunit_run_irq_test(test, polyval_irq_test_func, 200000, &state);
}
static int polyval_suite_init(struct kunit_suite *suite)
---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251230-kunit-polyval-fix-cd018aaabef1
Best regards,
--
Thomas Weißschuh <thomas.weissschuh@linutronix.de>
On Fri, Jan 02, 2026 at 08:32:03AM +0100, Thomas Weißschuh wrote:
> On my development machine the generic, memcpy()-only implementation of
> polyval_preparekey() is too fast for the IRQ workers to actually fire.
> The test fails.
>
> Increase the iterations to make the test more robust.
> The test will run for a maximum of one second in any case.
>
> Fixes: b3aed551b3fc ("lib/crypto: tests: Add KUnit tests for POLYVAL")
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Glad to see that people are running these tests! I actually already
applied
https://lore.kernel.org/linux-crypto/20251219085259.1163048-1-davidgow@google.com/
for this issue, which should be sufficient by itself. Might be worth
increasing the iteration count as well, but I'd like to check whether
any other tests could use a similar change as well.
- Eric
Le 03/01/2026 à 2:27 AM, Eric Biggers a écrit :
> On Fri, Jan 02, 2026 at 08:32:03AM +0100, Thomas Weißschuh wrote:
>> On my development machine the generic, memcpy()-only implementation of
>> polyval_preparekey() is too fast for the IRQ workers to actually fire.
>> The test fails.
>>
>> Increase the iterations to make the test more robust.
>> The test will run for a maximum of one second in any case.
>>
>> Fixes: b3aed551b3fc ("lib/crypto: tests: Add KUnit tests for POLYVAL")
>> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
>
> Glad to see that people are running these tests! I actually already
> applied
> https://lore.kernel.org/linux-crypto/20251219085259.1163048-1-davidgow@google.com/
> for this issue, which should be sufficient by itself. Might be worth
> increasing the iteration count as well, but I'd like to check whether
> any other tests could use a similar change as well.
>
The polyval one is the only one I got reliably, but I have just managed
to reproduce this with crc.ctct10dif_test as well.
[19:47:29] # crc_t10dif_test: EXPECTATION FAILED at
include/kunit/run-in-irq-context.h:112
[19:47:29] Expected state.hardirq_func_calls > 0, but
[19:47:29] state.hardirq_func_calls == 0 (0x0)
[19:47:29]
[19:47:29] Timer function was not called
[19:47:29] # crc_t10dif_test: EXPECTATION FAILED at
include/kunit/run-in-irq-context.h:114
[19:47:29] Expected state.softirq_func_calls > 0, but
[19:47:29] state.softirq_func_calls == 0 (0x0)
[19:47:29]
[19:47:29] BH work function was not called
[19:47:29] [FAILED] crc_t10dif_test
It's only happening for me on aarch64, with hardware virtualisation (and
it goes away if the crc test suite is the only one which gets run,
interestingly).
And, of course, all of the issues go away with the patch applied / with
-rc4.
Cheers,
-- David
On Fri, Jan 02, 2026 at 10:27:48AM -0800, Eric Biggers wrote:
> On Fri, Jan 02, 2026 at 08:32:03AM +0100, Thomas Weißschuh wrote:
> > On my development machine the generic, memcpy()-only implementation of
> > polyval_preparekey() is too fast for the IRQ workers to actually fire.
> > The test fails.
> >
> > Increase the iterations to make the test more robust.
> > The test will run for a maximum of one second in any case.
> >
> > Fixes: b3aed551b3fc ("lib/crypto: tests: Add KUnit tests for POLYVAL")
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
>
> Glad to see that people are running these tests! I actually already
> applied
> https://lore.kernel.org/linux-crypto/20251219085259.1163048-1-davidgow@google.com/
> for this issue, which should be sufficient by itself.
That works, too. Thanks!
> Might be worth
> increasing the iteration count as well, but I'd like to check whether
> any other tests could use a similar change as well.
No other one of the default tests failed for me in a similar way.
Thomas
On Mon, Jan 05, 2026 at 09:21:32AM +0100, Thomas Weißschuh wrote:
> On Fri, Jan 02, 2026 at 10:27:48AM -0800, Eric Biggers wrote:
> > On Fri, Jan 02, 2026 at 08:32:03AM +0100, Thomas Weißschuh wrote:
> > > On my development machine the generic, memcpy()-only implementation of
> > > polyval_preparekey() is too fast for the IRQ workers to actually fire.
> > > The test fails.
> > >
> > > Increase the iterations to make the test more robust.
> > > The test will run for a maximum of one second in any case.
> > >
> > > Fixes: b3aed551b3fc ("lib/crypto: tests: Add KUnit tests for POLYVAL")
> > > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> >
> > Glad to see that people are running these tests! I actually already
> > applied
> > https://lore.kernel.org/linux-crypto/20251219085259.1163048-1-davidgow@google.com/
> > for this issue, which should be sufficient by itself.
>
> That works, too. Thanks!
>
> > Might be worth
> > increasing the iteration count as well, but I'd like to check whether
> > any other tests could use a similar change as well.
>
> No other one of the default tests failed for me in a similar way.
>
>
> Thomas
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=libcrypto-fixes
I added the following note to the commit message:
[EB: This failure was already fixed by commit c31f4aa8fed0 ("kunit:
Enforce task execution in {soft,hard}irq contexts"). I'm still applying
this patch too, since the iteration count in this test made its running
time much shorter than the other similar ones.]
- Eric
© 2016 - 2026 Red Hat, Inc.