On Thu, Jul 06, 2006 at 03:17:55PM +1200, Michal Ludvig wrote:
>
> +static void padlock_sha_update(struct crypto_tfm *tfm, const uint8_t *data,
> unsigned int length)
> +{
> + if (unlikely(!CTX(tfm)->bypass && (CTX(tfm)->used + length >
> CTX(tfm)->data_len)))
> + padlock_sha_bypass(tfm);
Sorry, we can't do that here since padlock_sha_bypass may sleep (through
crypto_alloc_tfm) and crypto_digest_update can be called from atomic
contexts (e.g., IPsec).
I suggest that you always do the crypto_alloc_tfm in cra_init.
Also, you shouldn't hold a tfm object for the lifetime of the module.
The fallback tfm should only be allocated in cra_init. We don't want
the presence of padlock-sha to stop people from unloading/reloading
sha1-generic. In general, we only hold a module reference when a real
tfm has been allocated.
The crypto API is designed so that you can always update any algorithm
by doing
rmmod -w algo
modprobe algo-new
such that anyone who accesses algo will either get algo or algo-new
without failing.
So just keep the fallback name around and use that to allocate the
fallback tfm unconditionally in cra_init.
Once I've made the type/mask available to crypto_alloc_tfm we can
also get rid of the fallback module parameter and instead let the
crypto API pick the best fallback.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
