All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.