[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aB6veEHqgrxBJs01@gondor.apana.org.au>
Date: Sat, 10 May 2025 09:44:24 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Corentin Labbe <clabbe.montjoie@...il.com>
Cc: Klaus Kudielka <klaus.kudielka@...il.com>, regressions@...ts.linux.dev,
linux-kernel@...r.kernel.org,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
Boris Brezillon <bbrezillon@...nel.org>,
EBALARD Arnaud <Arnaud.Ebalard@....gouv.fr>,
Romain Perier <romain.perier@...il.com>
Subject: Re: [v3 PATCH] crypto: marvell/cesa - Do not chain submitted requests
On Sat, May 10, 2025 at 09:37:58AM +0800, Herbert Xu wrote:
>
> In particular, when testmgr does an update+final, it will give a
> non-NULL SG list to the final call.
This ties in with all the test results so far because it appears
that all the failed test vectors involve a final call.
> The buggy code in marvell/cesa will then read that non-NULL SG list
> during the final call and overwrite the cached bytes with it.
> However, I still can't see why that would make a difference because
> it should contain the same data.
I think I can see where it does make a difference. The SG list
is never mapped during the final call. So the DMA address is going
to be either crap or more likely the address from the previous
update call where it was mapped.
Now depending on how DMA mapping works on your platform, that may
indeed be buggy during concurrent calls only.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists