Message ID | Z-ULBwaDsgWpYzmU@gondor.apana.org.au (mailing list archive) |
---|---|
State | Superseded |
Delegated to: | Herbert Xu |
Headers | show |
Series | crypto: testmgr - Initialise full_sgl properly | expand |
Hi Herbert, On 16:23-20250327, Herbert Xu wrote: > On Thu, Mar 27, 2025 at 01:45:55PM +0530, Manorit Chawdhry wrote: > > > > [ 33.040345] sa_run: 1182: req->size: 40187, src: 00000000f1859ae0 > > [ 33.046426] sa_run: 1183: sgl: 00000000f1859ae0, orig_nents: -22 > > Thanks for the info! The filler SG initialisation was broken: > > ---8<--- > Initialise the whole full_sgl array rather than the first entry. > > Fixes: 8b54e6a8f415 ("crypto: testmgr - Add multibuffer hash testing") > Reported-by: Manorit Chawdhry <m-chawdhry@ti.com> > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> > Thanks, this fixes it. root@j721e-evm:~# modprobe sa2ul [ 35.293140] omap_rng 4e10000.rng: Random Number Generator ver. 241b34c Tested-by: Manorit Chawdhry <m-chawdhry@ti.com> Regards, Manorit
Hi Herbert, On 14:10-20250327, Manorit Chawdhry wrote: > Hi Herbert, > > On 16:23-20250327, Herbert Xu wrote: > > On Thu, Mar 27, 2025 at 01:45:55PM +0530, Manorit Chawdhry wrote: > > > > > > [ 33.040345] sa_run: 1182: req->size: 40187, src: 00000000f1859ae0 > > > [ 33.046426] sa_run: 1183: sgl: 00000000f1859ae0, orig_nents: -22 > > > > Thanks for the info! The filler SG initialisation was broken: > > > > ---8<--- > > Initialise the whole full_sgl array rather than the first entry. > > > > Fixes: 8b54e6a8f415 ("crypto: testmgr - Add multibuffer hash testing") > > Reported-by: Manorit Chawdhry <m-chawdhry@ti.com> > > Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> > > > > Thanks, this fixes it. Though it really makes me wonder.. I was actually thinking that it was our driver problem and not something core as when I fell back to the software fallbacks everything was fine... How is it possible, do you have any insights on that? Is something missing? [ Without this patch + the patch mentioned below ] diff --git a/drivers/crypto/sa2ul.c b/drivers/crypto/sa2ul.c index 35570c06eb3c..90d754bbea9b 100644 --- a/drivers/crypto/sa2ul.c +++ b/drivers/crypto/sa2ul.c @@ -1417,9 +1417,9 @@ static int sa_sha_run(struct ahash_request *req) if (!auth_len) return zero_message_process(req); - if (auth_len > SA_MAX_DATA_SZ || + if (1 || (auth_len > SA_MAX_DATA_SZ || (auth_len >= SA_UNSAFE_DATA_SZ_MIN && - auth_len <= SA_UNSAFE_DATA_SZ_MAX)) { + auth_len <= SA_UNSAFE_DATA_SZ_MAX))) { struct ahash_request *subreq = &rctx->fallback_req; int ret; This passes the tests. root@j721e-evm:~# modprobe sa2ul [ 53.380168] omap_rng 4e10000.rng: Random Number Generator ver. 241b34c Regards, Manorit > > root@j721e-evm:~# modprobe sa2ul > [ 35.293140] omap_rng 4e10000.rng: Random Number Generator ver. 241b34c > > Tested-by: Manorit Chawdhry <m-chawdhry@ti.com> > > Regards, > Manorit
On Thu, Mar 27, 2025 at 02:39:55PM +0530, Manorit Chawdhry wrote: > > Though it really makes me wonder.. I was actually thinking that it was > our driver problem and not something core as when I fell back to the > software fallbacks everything was fine... How is it possible, do you > have any insights on that? Is something missing? I think the software SG walker simply exits if it detects a shorter than expected SG list. So if you ask it to hash 128KB of data, but only supply an 8KB SG list, it will hash 8KB and then declare that the job is done. That is arguably suboptimal. I'm in the process of rewriting the software walker to add multibuffer support so I might fix this in the process. Cheers,
diff --git a/crypto/testmgr.c b/crypto/testmgr.c index 74b3cadc0d40..455ce6e434fd 100644 --- a/crypto/testmgr.c +++ b/crypto/testmgr.c @@ -689,7 +689,7 @@ static int build_test_sglist(struct test_sglist *tsgl, sg_init_table(tsgl->full_sgl, XBUFSIZE); for (i = 0; i < XBUFSIZE; i++) - sg_set_buf(tsgl->full_sgl, tsgl->bufs[i], PAGE_SIZE * 2); + sg_set_buf(&tsgl->full_sgl[i], tsgl->bufs[i], PAGE_SIZE * 2); return 0; }