Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 26 Jul 2021 10:29:08 +0200
From:   Corentin Labbe <clabbe.montjoie@gmail.com>
To:     Dongliang Mu <mudongliangabcd@gmail.com>
Cc:     Herbert Xu <herbert@gondor.apana.org.au>,
        "David S. Miller" <davem@davemloft.net>,
        Maxime Ripard <mripard@kernel.org>,
        Chen-Yu Tsai <wens@csie.org>,
        Jernej Skrabec <jernej.skrabec@gmail.com>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>,
        Eric Biggers <ebiggers@google.com>,
        Colin Ian King <colin.king@canonical.com>,
        Xiang Chen <chenxiang66@hisilicon.com>,
        Ard Biesheuvel <ardb@kernel.org>, linux-crypto@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] crypto: sun8i-ce: fix memory leak and return value of
 sun8i_ce_hash_run
Message-ID: <YP5yVIVTmNM7yMLZ@Red>
References: <20210726075957.2231287-1-mudongliangabcd@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20210726075957.2231287-1-mudongliangabcd@gmail.com>
Precedence: bulk

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 <mudongliangabcd@gmail.com>

"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")

> Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
> ---
> 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.

>  	__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