Herbert Xu wrote: > I suggest that you always do the crypto_alloc_tfm in cra_init.
OK. > 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. > [...] > So just keep the fallback name around and use that to allocate the > fallback tfm unconditionally in cra_init. Should I keep trying the test allocations in padlock_init_sha() and release them immediately? Probably not. This was a relict from times before cra_init()/cra_exit() when we had no error path from dia_init(). This way I ensured we will be able to allocate tfm. Not needed anymore, I agree. > 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. What will this type/mask indicate? Something like "I can't do more than one update?" ... would anything pick the module then? Michal - 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
