From: sashiko-bot@kernel.org
To: "Vincent Jardin" <vjardin@free.fr>,
"Horia Geantă" <horia.geanta@nxp.com>,
"Pankaj Gupta" <pankaj.gupta@nxp.com>,
"Sahil Malhotra" <sahil.malhotra@nxp.com>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>
Cc: linux-crypto@vger.kernel.org
Subject: Re: [PATCH RFC] crypto: caam - never share the gcm and skcipher descriptors serially
Date: Sun, 08 Nov 2026 23:55:52 +0000 [thread overview]
Message-ID: <sashiko-outbox-204176@kernel.org> (raw)
In-Reply-To: <20261109-for-upstream-caam-shdsc-share-never-v1-v1-1-65a1dd146db2@free.fr>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] crypto: caam: dead sharing jumps and HDR_SAVECTX with
HDR_SHARE_NEVER
--
commit 9b09bbe924ba4f39f4ea4b61b1bb908c38315173
Author: Vincent Jardin <vjardin@free.fr>
crypto: caam - never share the gcm and skcipher descriptors serially
This commit changes the GCM and skcipher shared descriptors from
HDR_SHARE_SERIAL to HDR_SHARE_NEVER so jobs using the same key are not
serialized by the SEC hardware.
> diff --git a/drivers/crypto/caam/caamalg_desc.c b/drivers/crypto/caam/caamalg_desc.c
> index 04c1105eb1f58..32d614a3431da 100644
> --- a/drivers/crypto/caam/caamalg_desc.c
> +++ b/drivers/crypto/caam/caamalg_desc.c
> @@ -639,7 +639,7 @@ void cnstr_shdsc_gcm_encap(u32 * const desc, struct alginfo *cdata,
> u32 *key_jump_cmd, *zero_payload_jump_cmd, *zero_assoc_jump_cmd1,
> *zero_assoc_jump_cmd2;
>
> - init_sh_desc(desc, HDR_SHARE_SERIAL);
> + init_sh_desc(desc, HDR_SHARE_NEVER);
>
> /* skip key loading if they are loaded due to sharing */
> key_jump_cmd = append_jump(desc, JUMP_JSL | JUMP_TEST_ALL |
> @@ -765,7 +765,7 @@ void cnstr_shdsc_gcm_decap(u32 * const desc, struct alginfo *cdata,
> {
> u32 *key_jump_cmd, *zero_payload_jump_cmd, *zero_assoc_jump_cmd1;
>
> - init_sh_desc(desc, HDR_SHARE_SERIAL);
> + init_sh_desc(desc, HDR_SHARE_NEVER);
>
> /* skip key loading if they are loaded due to sharing */
> key_jump_cmd = append_jump(desc, JUMP_JSL |
> @@ -1463,7 +1463,7 @@ void cnstr_shdsc_skcipher_encap(u32 * const desc, struct alginfo *cdata,
> bool is_chacha20 = ((cdata->algtype & OP_ALG_ALGSEL_MASK) ==
> OP_ALG_ALGSEL_CHACHA20);
>
> - init_sh_desc(desc, HDR_SHARE_SERIAL | HDR_SAVECTX);
> + init_sh_desc(desc, HDR_SHARE_NEVER | HDR_SAVECTX);
> /* Skip if already shared */
> key_jump_cmd = append_jump(desc, JUMP_JSL | JUMP_TEST_ALL |
> JUMP_COND_SHRD);
> @@ -1539,7 +1539,7 @@ void cnstr_shdsc_skcipher_decap(u32 * const desc, struct alginfo *cdata,
> bool is_chacha20 = ((cdata->algtype & OP_ALG_ALGSEL_MASK) ==
> OP_ALG_ALGSEL_CHACHA20);
>
> - init_sh_desc(desc, HDR_SHARE_SERIAL | HDR_SAVECTX);
> + init_sh_desc(desc, HDR_SHARE_NEVER | HDR_SAVECTX);
> /* Skip if already shared */
> key_jump_cmd = append_jump(desc, JUMP_JSL | JUMP_TEST_ALL |
> JUMP_COND_SHRD);
[Severity: Low]
With HDR_SHARE_NEVER, should HDR_SAVECTX and the JUMP_COND_SHRD jumps also
be dropped from these four descriptors?
All CAAM job backends defer sharing mode to the shared descriptor header,
so HDR_SHARE_NEVER disables descriptor sharing across jobs and JUMP_COND_SHRD
is never true. Keeping key_jump_cmd and the JUMP_COND_SHRD branch in
append_dec_op1() called by cnstr_shdsc_skcipher_decap() leaves unreachable
instructions in the descriptors that waste space and DECO cycles on every
job, and HDR_SAVECTX only applies when a descriptor is self-shared.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261109-for-upstream-caam-shdsc-share-never-v1-v1-1-65a1dd146db2@free.fr?part=1
next prev parent reply other threads:[~2026-11-08 23:55 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-08 23:42 [PATCH RFC] crypto: caam - never share the gcm and skcipher descriptors serially Vincent Jardin
2026-11-08 23:42 ` Vincent Jardin via B4 Relay
2026-11-08 23:55 ` sashiko-bot [this message]
2026-11-09 9:24 ` Vincent Jardin
2026-11-12 10:14 ` Sahil Malhotra
2026-11-13 0:23 ` Vincent Jardin
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=sashiko-outbox-204176@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=horia.geanta@nxp.com \
--cc=linux-crypto@vger.kernel.org \
--cc=pankaj.gupta@nxp.com \
--cc=sahil.malhotra@nxp.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=vjardin@free.fr \
/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.