linux-kernel - Re: [PATCH] crypto: marvell/cesa - Avoid empty transfer descriptor

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aC2p6xkMz4BtzPYH@gondor.apana.org.au>
Date: Wed, 21 May 2025 18:24:43 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Arnd Bergmann <arnd@...db.de>
Cc: Corentin Labbe <clabbe.montjoie@...il.com>,
	Klaus Kudielka <klaus.kudielka@...il.com>,
	Eric Biggers <ebiggers@...nel.org>, regressions@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
	"'bbrezillon@...nel.org'" <bbrezillon@...nel.org>,
	EBALARD Arnaud <Arnaud.Ebalard@....gouv.fr>,
	Romain Perier <romain.perier@...il.com>
Subject: Re: [PATCH] crypto: marvell/cesa - Avoid empty transfer descriptor

On Wed, May 21, 2025 at 11:58:49AM +0200, Arnd Bergmann wrote:
>
> I did not see the entire background of the discussion, but would
> point out that this is not supposed to work at all:

We're trying to find out why this driver fails under concurrent
load.  It works perfectly if you do one request at a time, but
when you hit it with load coming from both CPUs, it ends up
corrupting the data.

My suscipicion right now is DMA corruption.  One common thread
seems to be that if you only use dma_map_sg it works, but if
dma_alloc_coherent memory is used then it is corrupted (this
isn't proven yet, it's just what the printk patch was showing).

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