From: Christian Marangi <ansuelsmth@gmail.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Antoine Tenart <atenart@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
Waiman Long <longman@redhat.com>,
Boqun Feng <boqun.feng@gmail.com>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
linux-crypto@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev,
upstream@airoha.com, Richard van Schagen <vschagen@icloud.com>
Subject: Re: [PATCH v7 3/3] crypto: Add Inside Secure SafeXcel EIP-93 crypto engine support
Date: Tue, 10 Dec 2024 12:55:02 +0100 [thread overview]
Message-ID: <67582c1b.050a0220.83ef5.c8df@mx.google.com> (raw)
In-Reply-To: <Z1e0LHycNGcWqd2q@gondor.apana.org.au>
On Tue, Dec 10, 2024 at 11:23:24AM +0800, Herbert Xu wrote:
> On Tue, Nov 12, 2024 at 02:59:00AM +0100, Christian Marangi wrote:
> >
> > +static int eip93_hash_export(struct ahash_request *req, void *out)
> > +{
> > + struct eip93_hash_reqctx *rctx = ahash_request_ctx(req);
> > + struct eip93_hash_export_state *state = out;
> > + DECLARE_CRYPTO_WAIT(wait);
> > + int ret;
> > +
> > + crypto_init_wait(&wait);
> > + /* Set the req callback for hash_partial_final wait */
> > + ahash_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
> > + crypto_req_done, &wait);
> > +
> > + /* Set for partial hash generation */
> > + rctx->partial_hash = true;
> > + rctx->export_state = true;
> > + rctx->state = state;
> > +
> > + /* Save the first block in state data */
> > + if (rctx->left_last || rctx->len) {
> > + struct mkt_hash_block *block;
> > +
> > + block = list_first_entry(&rctx->blocks,
> > + struct mkt_hash_block,
> > + list);
> > +
> > + memcpy(state->data, block->data,
> > + SHA256_BLOCK_SIZE - rctx->left_last);
> > + }
> > +
> > + /* Call hash_partial_final.
> > + * This will send a dummpy 0 length packet. This is done to
> > + * wait for every descriptor to being handled and sync the sa_state
> > + * from the host. Partial hash and any other data will be copied in
> > + * eip93_hash_handle_result()
> > + */
> > + ret = crypto_wait_req(eip93_hash_partial_final(req), &wait);
>
> Sorry, you can't do that here. Your hash state should have been
> exported when the request previously completed. The export function
> must not sleep.
>
Ah that unfortunate but doesn't that goes against the async idea of ahash
OPs? Anyway is busy loop acceptable here?
The main problem here is that .update only enqueue packet to be
processed and we don't wait for it to finish as that would result in
really bad performance.
To export the state with the previous request (.update) we would have to
wait for each packet to complete or we would export the wrong partial
hash.
The process is fast enough so busy loop here should not be problematic
but waiting for every packet sent to .update on being processed might
introduce big performance regression.
Thanks for checking this hope you can help me understand this.
--
Ansuel
next prev parent reply other threads:[~2024-12-10 11:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-12 1:58 [PATCH v7 0/3] crypto: Add EIP-93 crypto engine support Christian Marangi
2024-11-12 1:58 ` [PATCH v7 1/3] spinlock: extend guard with spinlock_bh variants Christian Marangi
2024-11-12 1:58 ` [PATCH v7 2/3] dt-bindings: crypto: Add Inside Secure SafeXcel EIP-93 crypto engine Christian Marangi
2024-11-12 1:59 ` [PATCH v7 3/3] crypto: Add Inside Secure SafeXcel EIP-93 crypto engine support Christian Marangi
2024-12-09 23:27 ` Christian Marangi
2024-12-10 3:23 ` Herbert Xu
2024-12-10 11:55 ` Christian Marangi [this message]
2024-12-10 12:06 ` Herbert Xu
2024-12-10 12:16 ` Christian Marangi
2024-12-10 13:27 ` Herbert Xu
2024-12-10 20:51 ` Christian Marangi
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=67582c1b.050a0220.83ef5.c8df@mx.google.com \
--to=ansuelsmth@gmail.com \
--cc=atenart@kernel.org \
--cc=boqun.feng@gmail.com \
--cc=conor+dt@kernel.org \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=justinstitt@google.com \
--cc=krzk+dt@kernel.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=robh@kernel.org \
--cc=upstream@airoha.com \
--cc=vschagen@icloud.com \
--cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox