public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: neil.armstrong@linaro.org, linux-crypto@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
	Thara Gopinath <thara.gopinath@gmail.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	Stanimir Varbanov <svarbanov@mm-sol.com>
Subject: Re: [PATCH 9/9] crypto: qce - switch to using a mutex
Date: Sat, 18 Jan 2025 09:55:02 -0800	[thread overview]
Message-ID: <20250118175502.GA66612@sol.localdomain> (raw)
In-Reply-To: <CAMRc=MeFMYzMY4pU9D6fEpg9bQuuzqg4rQhBU8=z_2eMU+Py-g@mail.gmail.com>

On Sat, Jan 18, 2025 at 10:28:26AM +0100, Bartosz Golaszewski wrote:
> I was testing with kcapi-speed and cryptsetup benchmark. I've never
> seen any errors.
> 
> Is this after my changes only or did it exist before? You're testing
> with the tcrypt module? How are you inserting it exactly? What params?

Those are all benchmarks, not tests.  The tests run at registration time if you
just enable the kconfig options for them:

    # CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
    CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y

The test failures and KASAN error occur on mainline too, so yes they occur
before your patchset too.

> >
> > I personally still struggle to understand how this driver could plausibly be
> > useful when the software crypto has no issues, is much faster, and is much
> > better tested.  What is motivating having this driver in the kernel?
> 
> We want to use it in conjunction with the upcoming scminvoke (for
> loading TAs and invoking objects - used to program the keys into the
> QCE) to support the DRM use-case for decrypting streaming data inside
> secure buffers upstream.

Notably lacking is any claim that any of the current features of the driver are
actually useful.

- Eric

  reply	other threads:[~2025-01-18 17:55 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-03  9:19 [PATCH 0/9] crypto: qce - refactor the driver Bartosz Golaszewski
2024-12-03  9:19 ` [PATCH 1/9] crypto: qce - fix goto jump in error path Bartosz Golaszewski
2024-12-03 13:43   ` neil.armstrong
2024-12-03  9:19 ` [PATCH 2/9] crypto: qce - unregister previously registered algos " Bartosz Golaszewski
2024-12-03 13:55   ` neil.armstrong
2024-12-03 15:05     ` Bartosz Golaszewski
2024-12-04 10:17       ` neil.armstrong
2024-12-03  9:19 ` [PATCH 3/9] crypto: qce - remove unneeded call to icc_set_bw() " Bartosz Golaszewski
2024-12-03 13:45   ` neil.armstrong
2024-12-03  9:19 ` [PATCH 4/9] crypto: qce - shrink code with devres clk helpers Bartosz Golaszewski
2024-12-03 13:46   ` neil.armstrong
2024-12-03 18:32   ` Stephan Gerhold
2024-12-03 20:39     ` Bartosz Golaszewski
2024-12-03  9:19 ` [PATCH 5/9] crypto: qce - convert qce_dma_request() to use devres Bartosz Golaszewski
2024-12-03 13:49   ` neil.armstrong
2024-12-03  9:19 ` [PATCH 6/9] crypto: qce - make qce_register_algs() a managed interface Bartosz Golaszewski
2024-12-03 13:50   ` neil.armstrong
2024-12-03  9:19 ` [PATCH 7/9] crypto: qce - use __free() for a buffer that's always freed Bartosz Golaszewski
2024-12-03 13:52   ` neil.armstrong
2024-12-03  9:19 ` [PATCH 8/9] crypto: qce - convert tasklet to workqueue Bartosz Golaszewski
2024-12-03 13:52   ` neil.armstrong
2024-12-03  9:19 ` [PATCH 9/9] crypto: qce - switch to using a mutex Bartosz Golaszewski
2024-12-03 13:53   ` neil.armstrong
2024-12-03 15:10     ` Bartosz Golaszewski
2024-12-04 10:17       ` neil.armstrong
2025-01-18  8:06       ` Eric Biggers
2025-01-18  9:28         ` Bartosz Golaszewski
2025-01-18 17:55           ` Eric Biggers [this message]
2025-01-20 13:46             ` Bartosz Golaszewski
2025-02-20  9:14               ` Bartosz Golaszewski
2025-02-20 19:19                 ` Eric Biggers
2024-12-03 17:35 ` [PATCH 0/9] crypto: qce - refactor the driver Eric Biggers
2024-12-03 18:08   ` Eric Biggers
2024-12-03 20:55   ` Bartosz Golaszewski
2024-12-14  9:27 ` Herbert Xu

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=20250118175502.GA66612@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=bartosz.golaszewski@linaro.org \
    --cc=brgl@bgdev.pl \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=svarbanov@mm-sol.com \
    --cc=thara.gopinath@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox