On Wed, Sep 28, 2016 at 09:38:41AM -0300, Marcelo Cerri wrote: > > The patch forces ghash-generic as the fallback. And I don't think that > is a big problem if we decide to go by this path. Right it should work but could break for example if we ever decide to change the exported state structure for ghash and someone unloads the ghash-generic module and reloads a new one. > That would be nice because it would allow p8_ghash to keep using a > dynamic fallback, but I'm not that is viable. What do you think? We did it for SHA because it was desirable to have multiple fallbacks, i.e., a generic C version plus an assembly-optimised version. Not sure whether the same motiviation exists for GHASH. > > Otherwise we can go back to allocating just ghash-generic and > > also move its data structure into an exported header file. > > > > That would make the fix much more simple and it wouldn't require to get > the fallback descsize at runtime. This is the easiest fix so let's go with this now. If we ever care enough to have multiple fallbacks for GHASH we can always revisit this. The exported format is not exposed to user-space so it can always be changed. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
