lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABVgOSmr4HEbOVKs1FZEmP_xwDExDxB8JZjFy0gfZWj01fqByQ@mail.gmail.com>
Date: Sat, 20 Dec 2025 14:37:22 +0800
From: David Gow <davidgow@...gle.com>
To: Eric Biggers <ebiggers@...nel.org>
Cc: Brendan Higgins <brendan.higgins@...ux.dev>, Rae Moar <raemoar63@...il.com>, 
	Shuah Khan <skhan@...uxfoundation.org>, linux-kselftest@...r.kernel.org, 
	kunit-dev@...glegroups.com, linux-kernel@...r.kernel.org, 
	linux-crypto@...r.kernel.org
Subject: Re: [PATCH v2] kunit: Enforce task execution in {soft,hard}irq contexts

On Sat, 20 Dec 2025 at 03:05, Eric Biggers <ebiggers@...nel.org> wrote:
>
> On Fri, Dec 19, 2025 at 04:52:58PM +0800, David Gow wrote:
> > The kunit_run_irq_test() helper allows a function to be run in hardirq
> > and softirq contexts (in addition to the task context). It does this by
> > running the user-provided function concurrently in the three contexts,
> > until either a timeout has expired or a number of iterations have
> > completed in the normal task context.
> >
> > However, on setups where the initialisation of the hardirq and softirq
> > contexts (or, indeed, the scheduling of those tasks) is significantly
> > slower than the function execution, it's possible for that number of
> > iterations to be exceeded before any runs in irq contexts actually
> > occur. This occurs with the polyval.test_polyval_preparekey_in_irqs
> > test, which runs 20000 iterations of the relatively fast preparekey
> > function, and therefore fails often under many UML, 32-bit arm, m68k and
> > other environments.
> >
> > Instead, ensure that the max_iterations limit counts executions in all
> > three contexts, and requires at least one of each. This will cause the
> > test to continue iterating until at least the irq contexts have been
> > tested, or the 1s wall-clock limit has been exceeded. This causes the
> > test to pass in all of my environments.
> >
> > In so doing, we also update the task counters to atomic ints, to better
> > match both the 'int' max_iterations input, and to ensure they are
> > correctly updated across contexts.
> >
> > Finally, we also fix a few potential assertion messages to be
> > less-specific to the original crypto usecases.
> >
> > Fixes: b41dc83f0790 ("kunit, lib/crypto: Move run_irq_test() to common header")
> > Signed-off-by: David Gow <davidgow@...gle.com>
> > ---
> >
> > Changes since v1:
> > https://lore.kernel.org/all/20251219080850.921416-1-davidgow@google.com/
> > - Remove a leftover debug line which forced max_iterations to 1.
>
> Thanks!  I'd like to take this through libcrypto-fixes, if that's okay
> with the KUnit folks (acks would be appreciated).  kunit_run_irq_test()
> is a recently-added helper function used by the crypto and CRC tests.

No worries: I don't think there are any other tests using this at the
moment; certainly nothing that needs the fix.

> For the Fixes commit, we should use the initial addition of this code:
>
>     Fixes: 950a81224e8b ("lib/crypto: tests: Add hash-test-template.h and gen-hash-testvecs.py")

Sounds good: I'm sure it'll be a tiny bit trickier to backport this
(and, e.g, the changes to the error messages aren't useful) to older
branches (and certainly I never saw any issues prior to the polyval
tests), but it is technically more correct, which is the best kind of
correct. :-)

Cheers,
-- David

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5281 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ