| Message ID | 1466601840-18486-7-git-send-email-t-kristo@ti.com |
|---|---|
| State | New |
| Headers | show |
On 24/06/16 13:32, Herbert Xu wrote: > On Wed, Jun 22, 2016 at 04:23:39PM +0300, Tero Kristo wrote: >> The statesize is used to determine the maximum size for saved ahash >> context. In some cases, this can be much larger than what is currently >> allocated for it, for example omap-sham driver uses a buffer size of >> PAGE_SIZE. Increase the statesize to accommodate this. >> >> Signed-off-by: Tero Kristo <t-kristo@ti.com> > > Nack. The exported state is supposed to consist of the actual > hash state, plus at most one block worth of unhashed data. It's > limited so that we can store it on the stack. > > So no I'm not taking this patch. > Ok, I think I need to allocate the storage space locally then within the driver. Would it be ok to call kmalloc / free in the export / import implementation of the driver? The size of the unhashed buffer in omap-sham is unfortunately rather large. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 27/06/16 08:00, Herbert Xu wrote: > On Mon, Jun 27, 2016 at 07:58:43AM +0300, Tero Kristo wrote: >> >> Ok, I think I need to allocate the storage space locally then within >> the driver. Would it be ok to call kmalloc / free in the export / >> import implementation of the driver? The size of the unhashed buffer >> in omap-sham is unfortunately rather large. > > The allocation should usually be done from the request_alloc > function, i.e., you set the reqsize and the user does the allocation > for you. I need some clarification on this, afaik request_alloc related functionality only works per-request basis. The export / import functionality however is supposed to work across multiple requests. The test code for example does this: ret = crypto_ahash_export(req, state); ... ahash_request_free(req); req = ahash_request_alloc(tfm, GFP_KERNEL); ... ret = crypto_ahash_import(req, state); ... which means if I attempt to allocate extra space for the export buffer within the first request, it is not available at the import time anymore. Is there any limitation how many simultaneous exports can be done from a driver? I was wondering if I can allocate a single export buffer for the whole driver. -Tero -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/crypto/ahash.c b/crypto/ahash.c index 3887a98..375bbd7 100644 --- a/crypto/ahash.c +++ b/crypto/ahash.c @@ -536,7 +536,7 @@ static int ahash_prepare_alg(struct ahash_alg *alg) struct crypto_alg *base = &alg->halg.base; if (alg->halg.digestsize > PAGE_SIZE / 8 || - alg->halg.statesize > PAGE_SIZE / 8 || + alg->halg.statesize > PAGE_SIZE * 2 || alg->halg.statesize == 0) return -EINVAL;
The statesize is used to determine the maximum size for saved ahash context. In some cases, this can be much larger than what is currently allocated for it, for example omap-sham driver uses a buffer size of PAGE_SIZE. Increase the statesize to accommodate this. Signed-off-by: Tero Kristo <t-kristo@ti.com> --- crypto/ahash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html