Re: [PATCH 00/20] crypto: introduce crypto_shash_tfm_digest()

Hi Eric, > This series introduces a helper function crypto_shash_tfm_digest() which > replaces the following common pattern: > > { > SHASH_DESC_ON_STACK(desc, tfm); > int err; > > desc->tfm = tfm; > > err = crypto_shash_digest(desc,

[PATCH] lib/xxhash: make xxh{32,64}_update() return void

From: Eric Biggers The return value of xxh64_update() is pointless and confusing, since an error is only returned for input==NULL. But the callers must ignore this error because they might pass input=NULL, length=0. Likewise for xxh32_update(). Just make these functions return void. Cc: Nikol

[PATCH] ubifs: fix wrong use of crypto_shash_descsize()

From: Eric Biggers crypto_shash_descsize() returns the size of the shash_desc context needed to compute the hash, not the size of the hash itself. crypto_shash_digestsize() would be correct, or alternatively using c->hash_len and c->hmac_desc_len which already store the correct values. But actua

[PATCH 03/20] crypto: essiv - use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Signed-off-by: Eric Biggers --- crypto/essiv.c | 4 +--- 1 file changed, 1 insertion

[PATCH 11/20] crypto: s5p-sss - use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Cc: Krzysztof Kozlowski Cc: Vladimir Zapolskiy Cc: Kamil Konieczny Signed-off-by: E

[PATCH 08/20] crypto: mediatek - use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Signed-off-by: Eric Biggers --- drivers/crypto/mediatek/mtk-sha.c | 7 ++- 1 fil

[PATCH 07/20] crypto: hisilicon/sec2 - use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Cc: Zaibo Xu Signed-off-by: Eric Biggers --- drivers/crypto/hisilicon/sec2/sec_cryp

[PATCH 09/20] crypto: n2 - use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Signed-off-by: Eric Biggers --- drivers/crypto/n2_core.c | 7 ++- 1 file changed

[PATCH 17/20] Bluetooth: use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Cc: linux-blueto...@vger.kernel.org Signed-off-by: Eric Biggers --- net/bluetooth/sm

[PATCH 05/20] crypto: ccp - use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Cc: Tom Lendacky Signed-off-by: Eric Biggers --- drivers/crypto/ccp/ccp-crypto-sha.

[PATCH 00/20] crypto: introduce crypto_shash_tfm_digest()

This series introduces a helper function crypto_shash_tfm_digest() which replaces the following common pattern: { SHASH_DESC_ON_STACK(desc, tfm); int err; desc->tfm = tfm; err = crypto_shash_digest(desc, data, len, out);

[PATCH 01/20] crypto: hash - introduce crypto_shash_tfm_digest()

From: Eric Biggers Currently the simplest use of the shash API is to use crypto_shash_digest() to digest a whole buffer. However, this still requires allocating a hash descriptor (struct shash_desc). Many users don't really want to preallocate one and instead just use a one-off descriptor on th

[PATCH 12/20] nfc: s3fwrn5: use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Cc: Robert Baldyga Cc: Krzysztof Opasiak Signed-off-by: Eric Biggers --- drivers/n

[PATCH 06/20] crypto: ccree - use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Cc: Gilad Ben-Yossef Signed-off-by: Eric Biggers --- drivers/crypto/ccree/cc_cipher

[PATCH 02/20] crypto: arm64/aes-glue - use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Signed-off-by: Eric Biggers --- arch/arm64/crypto/aes-glue.c | 4 +--- 1 file change

[PATCH 18/20] sctp: use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Cc: linux-s...@vger.kernel.org Signed-off-by: Eric Biggers --- net/sctp/auth.c

[PATCH 04/20] crypto: artpec6 - use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Cc: Jesper Nilsson Cc: Lars Persson Signed-off-by: Eric Biggers --- drivers/crypto

[PATCH 14/20] ecryptfs: use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Cc: ecryp...@vger.kernel.org Signed-off-by: Eric Biggers --- fs/ecryptfs/crypto.c |

[PATCH 15/20] nfsd: use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Cc: linux-...@vger.kernel.org Signed-off-by: Eric Biggers --- fs/nfsd/nfs4recover.c

[PATCH 20/20] ASoC: cros_ec_codec: use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Cc: Cheng-Yi Chiang Cc: Enric Balletbo i Serra Cc: Guenter Roeck Signed-off-by: Eri

[PATCH 13/20] fscrypt: use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Signed-off-by: Eric Biggers --- fs/crypto/fname.c | 7 +-- fs/crypto/hkdf.c | 6

[PATCH 16/20] ubifs: use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Cc: linux-...@lists.infradead.org Signed-off-by: Eric Biggers --- fs/ubifs/auth.c

[PATCH 19/20] KEYS: encrypted: use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Cc: keyri...@vger.kernel.org Signed-off-by: Eric Biggers --- security/keys/encrypted

[PATCH 10/20] crypto: omap-sham - use crypto_shash_tfm_digest()

From: Eric Biggers Instead of manually allocating a 'struct shash_desc' on the stack and calling crypto_shash_digest(), switch to using the new helper function crypto_shash_tfm_digest() which does this for us. Signed-off-by: Eric Biggers --- drivers/crypto/omap-sham.c | 20

[PATCH 1/1] mm/zswap: move to use crypto_acomp API for hardware acceleration

right now, new drivers are adapted to crypto_acomp APIs rather than crypto_comp APIs. Tradiontal compressors like lz4,lzo etc have been wrapped into acomp via scomp backend as well. To use the new hardware acceleration for compression, zswap should move to use acomp APIs. Platforms without async ac

[PATCH 0/1] mm/zswap: move to use crypto_acomp APIs

Hi Seth, Dan, Vitaly, Herbert, Using crypto_comp APIs, zswap is not able to use the hardware accelators which are only ported to cryto_acomp nowadays. So Mahipal Challa tried to solve this problem by the below patch a long time ago: mm: zswap - Add crypto acomp/scomp framework support [1] At that

Re: [PATCH v2] crypto: lib/sha256 - return void

On Fri, May 01, 2020 at 09:42:29AM -0700, Eric Biggers wrote: > From: Eric Biggers > > The SHA-256 / SHA-224 library functions can't fail, so remove the > useless return value. Looks good to me, and also matches the signatures of the blake2s library functions, which return null. Reviewed-by: Ja

[PATCH RFC] Frequent connection loss using krb5[ip] NFS mounts

Hi- Over the past year or so I've observed that using sec=krb5i or sec=krb5p with NFS/RDMA while testing my Linux NFS client and server results in frequent connection loss. I've been able to pin this down a bit. The problem is that SUNRPC's calls into the kernel crypto functions can sometimes res

[PATCH RFC] SUNRPC: crypto calls should never schedule

Do not allow the crypto core to reschedule while processing RPC requests. gss_krb5_crypto.c does make crypto API calls in process context. However: - When handling a received Call, rescheduling can introduce latencies that result in processing delays causing a request to fall outside the GSS seque

WARNING: refcount bug in crypto_mod_get

Hello, syzbot found the following crash on: HEAD commit:6a8b55ed Linux 5.7-rc3 git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=11b9156410 kernel config: https://syzkaller.appspot.com/x/.config?x=5b075813ec8b93cd dashboard link: https://syzkaller.appspot

[PATCH v2] crypto: lib/sha256 - return void

From: Eric Biggers The SHA-256 / SHA-224 library functions can't fail, so remove the useless return value. Also long as the declarations are being changed anyway, also fix some parameter names in the declarations to match the definitions. Signed-off-by: Eric Biggers --- v2: remove unnecessary

Re: [PATCH] crypto: lib/sha256 - return void

On Fri, May 01, 2020 at 02:28:12PM +0200, Christophe Leroy wrote: > > -extern int sha256_update(struct sha256_state *sctx, const u8 *input, > > -unsigned int length); > > -extern int sha256_final(struct sha256_state *sctx, u8 *hash); > > +extern void sha256_update(struct sha256_

Re: [PATCH] crypto: lib/sha256 - return void

Le 01/05/2020 à 09:13, Eric Biggers a écrit : From: Eric Biggers The SHA-256 / SHA-224 library functions can't fail, so remove the useless return value. Also long as the declarations are being changed anyway, also fix some parameter names in the declarations to match the definitions. Signe

RE: [PATCH char-misc-next] crypto: xilinx: Handle AES PM API return status

Thanks Gerg for review. I have updated reported by and fixes tag properly now. Sent v2. Thanks Rajan > -Original Message- > From: Greg KH > Sent: Friday, May 1, 2020 4:00 PM > To: Rajan Vaja > Cc: herb...@gondor.apana.org.au; da...@davemloft.net; Kalyani Akula > ; Michal Simek ; Jolly

[PATCH char-misc-next v2] crypto: xilinx: Handle AES PM API return status

Return value of AES PM API is not handled which may result in unexpected value of "status" in zynqmp_pm_aes_engine(). Consider "status" value as valid only if AES PM API is successful. Fixes: bc86f9c54616 ("firmware: xilinx: Remove eemi ops for aes engine") Reported-by: Stephen Rothwell Signed-o

Re: [PATCH char-misc-next] crypto: xilinx: Handle AES PM API return status

On Fri, May 01, 2020 at 03:14:51AM -0700, Rajan Vaja wrote: > Fixes: bc86f9c54616 ("firmware: xilinx: Remove eemi ops for aes engine") > > Return value of AES PM API is not handled which may result in > unexpected value of "status" in zynqmp_pm_aes_engine(). > > Consider "status" value as valid o

[PATCH char-misc-next] crypto: xilinx: Handle AES PM API return status

Fixes: bc86f9c54616 ("firmware: xilinx: Remove eemi ops for aes engine") Return value of AES PM API is not handled which may result in unexpected value of "status" in zynqmp_pm_aes_engine(). Consider "status" value as valid only if AES PM API is successful. Signed-off-by: Rajan Vaja --- driver

[PATCH] crypto: lib/sha256 - return void

From: Eric Biggers The SHA-256 / SHA-224 library functions can't fail, so remove the useless return value. Also long as the declarations are being changed anyway, also fix some parameter names in the declarations to match the definitions. Signed-off-by: Eric Biggers --- crypto/sha256_generic.