On Tue, Jul 18, 2017 at 03:52:19PM +0300, Tudor Ambarus wrote: > > I'm replacing a per-tfm shared secret with a per-request dynamically > allocated shared secret. The same for the public key, I'm replacing > a per-tfm public key with a per-request dynamically allocated public > key. No shared memory, no concurrency. For the pre-request bits that's fine. But in setkey you're still allocating a per-tfm data structure instead of just putting things into the tfm context. This is totally pointless. > For the private key I wanted to be sure that we don't interleave data > from multiple setkey calls. As of now, the setkey calls can fight to > memcopy to the same zone of memory. I'm making sure that the private key > is valid and not a mash of multiple private keys. As I said, if the caller is making simultaneous setkey calls then it's broken. You can never fix that in your driver, so don't even try. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
