All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Latypov <dlatypov@google.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: davem@davemloft.net, linux-crypto@vger.kernel.org,
	brendanhiggins@google.com, davidgow@google.com,
	linux-kernel@vger.kernel.org, kunit-dev@googlegroups.com
Subject: Re: [RFC v1 1/2] crypto: tcrypt: minimal conversion to run under KUnit
Date: Fri, 23 Jul 2021 12:31:28 -0700	[thread overview]
Message-ID: <CAGS_qxqOD+Bcvy7xti7_eg8+H1cJcfp94BtnRhuzijDcaGF_uA@mail.gmail.com> (raw)
In-Reply-To: <20210723064328.GA7986@gondor.apana.org.au>

On Thu, Jul 22, 2021 at 11:43 PM Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Thu, Jul 15, 2021 at 02:31:37PM -0700, Daniel Latypov wrote:
> >> == Questions ==
> > * does this seem like it would make running the test easier?
>
> I don't mind.  tcrypt these days isn't used so much for correctness
> testing.  It's mostly being used for speed testing.  A secondary
> use is to instantiate templates.

Thanks, that makes a lot of sense.
In that case, how useful would `kunit.py run` be? I.e. Do people
mostly want to see numbers on bare metal?

The default mode of `kunit.py run` is to use ARCH=um.
I assume (for at least most of the library-type crypto code) it should
have the same performance characteristics, but that might not be the
case. I can try and get some numbers on that.

There's an option to make `kunit.py run` use ARCH=86_64, but it'll be
in a QEMU VM, so again there's some performance overhead.

If either option seems useful, then perhaps a minimal patch like this
would be beneficial.
I can make it even smaller and less intrusive by restoring the "ret +=
..." code and having a single `KUNIT_EXPECT_EQ_MSG(test, ret, 0, "at
least one test case failed")` at the very end.

It does not sound like patch #2 or any future attempts to try and make
use of KUnit features is necessarily worth it, if correctness testing
isn't really the goal of tcrypt.c anymore.

>
> > * does `tvmem` actually need page-aligned buffers?
>
> I think it may be needed for those split-SG test cases where
> we deliberately create a buffer that straddles a page boundary.
>
> > * I have no clue how FIPS intersects with all of this.
>
> It doesn't really matter because in FIPS mode when a correctness
> test fails the kernel panics.
>
> >   * would it be fine to leave the test code built-in for FIPS instead of
> >   returning -EAGAIN?
>
> The returning -EAGAIN is irrelevant in FIPS mode.  It's more of
> an aid in normal mode when you use tcrypt for speed testing.
>
> Thanks,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

  reply	other threads:[~2021-07-23 19:31 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-15 21:31 [RFC v1 0/2] crypto: tcrypt: small changes to run under KUnit Daniel Latypov
2021-07-15 21:31 ` [RFC v1 1/2] crypto: tcrypt: minimal conversion " Daniel Latypov
2021-07-23  6:43   ` Herbert Xu
2021-07-23 19:31     ` Daniel Latypov [this message]
2021-07-30  2:55       ` Herbert Xu
2021-07-30  5:33         ` David Gow
2021-07-15 21:31 ` [RFC v1 2/2] crypto: tcrypt: call KUNIT_FAIL() instead of pr_err() Daniel Latypov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGS_qxqOD+Bcvy7xti7_eg8+H1cJcfp94BtnRhuzijDcaGF_uA@mail.gmail.com \
    --to=dlatypov@google.com \
    --cc=brendanhiggins@google.com \
    --cc=davem@davemloft.net \
    --cc=davidgow@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.