[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180419034210.nsmzuf3f6lmn7suc@gondor.apana.org.au>
Date: Thu, 19 Apr 2018 11:42:11 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Jan Glauber <jglauber@...ium.com>
Cc: "David S . Miller" <davem@...emloft.net>,
linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org,
Mahipal Challa <mchalla@...ium.com>,
Balakrishna Bhamidipati <bbhamidipati@...ium.com>
Subject: Re: [PATCH] crypto: testmgr: Allow different compression results
On Wed, Apr 11, 2018 at 08:28:32PM +0200, Jan Glauber wrote:
>
> @@ -1362,7 +1373,17 @@ static int test_comp(struct crypto_comp *tfm,
> goto out;
> }
>
> - if (dlen != ctemplate[i].outlen) {
> + ilen = dlen;
> + dlen = COMP_BUF_SIZE;
> + ret = crypto_comp_decompress(tfm, output,
> + ilen, decomp_output, &dlen);
> + if (ret) {
> + pr_err("alg: comp: compression failed: decompress: on test %d for %s failed: ret=%d\n",
> + i + 1, algo, -ret);
> + goto out;
> + }
> +
> + if (dlen != ctemplate[i].inlen) {
> printk(KERN_ERR "alg: comp: Compression test %d "
> "failed for %s: output len = %d\n", i + 1, algo,
> dlen);
Your patch is fine as it is.
But I just thought I'd mention that if anyone wants to we should
really change this to use a different tfm, e.g., always use the
generic algorithm to perform the decompression. This way if there
were multiple implementations we can at least test them against
the generic one.
Otherwise you could end up with a buggy implementation that works
against itself but still generates incorrect output.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists