Re: "crypto_hash_setkey" call from atomic context

[Fabrizio Demaria <fabrizio.f.demaria@gmail.com>]

In our MPTCP implementation we handled the setkey problem by
pre-allocating a properly aligned key's buffer right after
"crypto_alloc_hash", outside atomic context [1]. Would this workaround
be enough to guarantee that "crypto_hash_setkey" can be safely called
in atomic contexts? Is it always the case that "crypto_hash_setkey"
calls "crypto_shash_setkey"?

Thanks,
Fabrizio

[1] https://github.com/multipath-tcp/mptcp_net-next/commit/06e7644bdac1ac6e97767bc714586fbfadcdeaa8

2015-12-11 8:42 GMT+01:00 Herbert Xu <herbert@gondor.apana.org.au>:
> Fabrizio Demaria <fabrizio.f.demaria@gmail.com> wrote:
>> Hello,
>>
>> I am investigating the current usage of kernel crypto-libraries in the
>> SCTP code, considering to adopt the same crypto framework for the
>> MPTCP implementation.
>>
>> In sm_make_chunk.c, the crypto function "crypto_hash_setkey" is called
>> in an atomic context, despite the fact that this function CAN invoke a
>> GFP_KERNEL (sleeping) memory allocation. Calling a sleeping function
>> from an atomic context can end up in deadlock.
>> Is there a way to make sure that “crypto_hash_setkey” can be safely
>> called in an atomic context, considering all the possible code-paths
>> followed by the function?
>
> Indeed, in general setkey should not be invoked in atomic contexts.
> The only exception would be extremely simple hashes such as CRC.
>
> Keys should be setup before hand.  So SCTP needs to be fixed.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt