Re: [PATCH v2] crypto: sun8i-ce: fix memory leak and return value of sun8i_ce_hash_run
From: Corentin Labbe <clabbe.montjoie@gmail.com>
Date: 2021-07-26 08:29:17
Also in:
linux-crypto, linux-sunxi, lkml
Le Mon, Jul 26, 2021 at 03:59:36PM +0800, Dongliang Mu a écrit :
This patch fixes some memory leak caused by dma_mmap_sg/single in the error handling code. In addition, it fixes the return value when errors related with dma_mmap_sg/single occur.
Hello "some" is too imprecise, exactly which allocation is leaked ? In fact it will be easier to say that all dma_map_xx are leaked, I just saw that my code is really bad. Furthermore, you should have two fixes, one for the memory leak, one for the error code. But for the error code, I am not sure it is needed, error code is already given to user via crypto_finalize_hash_request(). The "return 0" is for crypto/crypto_engine API, returning an error will not change anything since we dont have retry_support. So I propose you to focus on dma_map_xxx() fix patch.
Reported-by: Dongliang Mu <redacted>
"Reported-by:" is for credit when someone else give you informations.
Fixes: 732b764099f65 ("crypto: sun8i-ce - fix two error path's memory leak")This is not the patch which introduces the problem, the problem is from the beginning ("crypto: sun8i-ss - support hash algorithms")
quoted hunk ↗ jump to hunk
Signed-off-by: Dongliang Mu <redacted> --- v1->v2: move crypto_finalize_hash_request to the end of function; move the memcpy after the dma_mmap_sg/single functions. .../crypto/allwinner/sun8i-ss/sun8i-ss-hash.c | 28 +++++++++---------- 1 file changed, 14 insertions(+), 14 deletions(-)diff --git a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c index 3c073eb3db03..fe5db3c84754 100644 --- a/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c +++ b/drivers/crypto/allwinner/sun8i-ss/sun8i-ss-hash.c@@ -324,11 +324,10 @@ int sun8i_ss_hash_run(struct crypto_engine *engine, void *breq) struct sun8i_ss_alg_template *algt; struct sun8i_ss_dev *ss; struct scatterlist *sg; - int nr_sgs, err, digestsize; + int j, i, todo, nr_sgs, digestsize, err; unsigned int len; u64 fill, min_fill, byte_count; void *pad, *result; - int j, i, todo;
This is a change unrelated with the subject.
quoted hunk ↗ jump to hunk
__be64 *bebits; __le64 *lebits; dma_addr_t addr_res, addr_pad;@@ -368,14 +367,14 @@ int sun8i_ss_hash_run(struct crypto_engine *engine, void *breq) if (nr_sgs <= 0 || nr_sgs > MAX_SG) { dev_err(ss->dev, "Invalid sg number %d\n", nr_sgs); err = -EINVAL; - goto theend; + goto err_result; } addr_res = dma_map_single(ss->dev, result, digestsize, DMA_FROM_DEVICE); if (dma_mapping_error(ss->dev, addr_res)) { dev_err(ss->dev, "DMA map dest\n"); err = -EINVAL; - goto theend; + goto err_unmap_sg; } len = areq->nbytes;@@ -390,7 +389,7 @@ int sun8i_ss_hash_run(struct crypto_engine *engine, void *breq) if (len > 0) { dev_err(ss->dev, "remaining len %d\n", len); err = -EINVAL; - goto theend; + goto err_addr_res; } byte_count = areq->nbytes;@@ -421,27 +420,28 @@ int sun8i_ss_hash_run(struct crypto_engine *engine, void *breq) } addr_pad = dma_map_single(ss->dev, pad, j * 4, DMA_TO_DEVICE); - rctx->t_src[i].addr = addr_pad; - rctx->t_src[i].len = j; - rctx->t_dst[i].addr = addr_res; - rctx->t_dst[i].len = digestsize / 4; if (dma_mapping_error(ss->dev, addr_pad)) { dev_err(ss->dev, "DMA error on padding SG\n"); err = -EINVAL; - goto theend; + goto err_addr_res; } + rctx->t_src[i].addr = addr_pad; + rctx->t_src[i].len = j; + rctx->t_dst[i].addr = addr_res; + rctx->t_dst[i].len = digestsize / 4;
This is right, it is useless to set addr_pad if it is "bad". But this is a change unrelated with the subject. Regards _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel