Re: [PATCH v2 0/4] Additional fixes on Talitos driver

[Christophe Leroy <christophe.leroy@c-s.fr>]

Le 12/06/2019 à 15:59, Horia Geanta a écrit :
> On 6/12/2019 8:52 AM, Christophe Leroy wrote:
>>
>>
>> Le 11/06/2019 à 18:30, Horia Geanta a écrit :
>>> On 6/11/2019 6:40 PM, Christophe Leroy wrote:
>>>>
>>>>
>>>> Le 11/06/2019 à 17:37, Horia Geanta a écrit :
>>>>> On 6/11/2019 5:39 PM, Christophe Leroy wrote:
>>>>>> This series is the last set of fixes for the Talitos driver.
>>>>>>
>>>>>> We now get a fully clean boot on both SEC1 (SEC1.2 on mpc885) and
>>>>>> SEC2 (SEC2.2 on mpc8321E) with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
>>>>>>
>>>>> I am getting below failures on a sec 3.3.2 (p1020rdb) for hmac(sha384) and
>>>>> hmac(sha512):
>>>>
>>>> Is that new with this series or did you already have it before ?
>>>>
>>> Looks like this happens with or without this series.
>>
>> Found the issue, that's in
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=b8fbdc2bc4e71b62646031d5df5f08aafe15d5ad
>>
>> CONFIG_CRYPTO_DEV_TALITOS_SEC2 should be CONFIG_CRYPTO_DEV_TALITOS2 instead.
>>
>> Just sent a patch to fix it.
>>
> Thanks, I've tested it and the hmac failures go away.
> 
> However, testing gets stuck.
> Seems there is another issue lurking in the driver.
> 
> Used cryptodev-2.6/master with the following on top:
> crypto: testmgr - add some more preemption points
> 	https://patchwork.kernel.org/patch/10972337/
> crypto: talitos - fix max key size for sha384 and sha512
> 	https://patchwork.kernel.org/patch/10988473/
> 
> [...]
> alg: skcipher: skipping comparison tests for ecb-3des-talitos because ecb(des3_ede-generic) is unavailable
> INFO: task cryptomgr_test:314 blocked for more than 120 seconds.
>        Not tainted 5.2.0-rc1-g905bfd415e8a #1
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> cryptomgr_test  D    0   314      2 0x00000800
> Call Trace:
> [e78337e0] [00000004] 0x4 (unreliable)
> [e78338a8] [c08a6e5c] __schedule+0x20c/0x4d4
> [e78338f8] [c08a7158] schedule+0x34/0xc8
> [e7833908] [c08aa5ec] schedule_timeout+0x1d4/0x350
> [e7833958] [c08a7be4] wait_for_common+0xa0/0x164
> [e7833998] [c03a7b14] do_ahash_op+0xa4/0xc4
> [e78339b8] [c03aba00] test_ahash_vec_cfg+0x188/0x5e4
> [e7833aa8] [c03ac1c8] test_hash_vs_generic_impl+0x1b0/0x2b4
> [e7833de8] [c03ac498] __alg_test_hash+0x1cc/0x2d0
> [e7833e28] [c03a9fb4] alg_test.part.37+0x8c/0x3ac
> [e7833ef8] [c03a54d0] cryptomgr_test+0x4c/0x54
> [e7833f08] [c006c410] kthread+0xf8/0x124
> [e7833f38] [c001227c] ret_from_kernel_thread+0x14/0x1c
> 
> addr2line on c03aba00 points to crypto/testmgr.c:1335
> 
>     1327)  if (cfg->finalization_type == FINALIZATION_TYPE_DIGEST ||
>     1328)      vec->digest_error) {
>     1329)          /* Just using digest() */
>     1330)          ahash_request_set_callback(req, req_flags, crypto_req_done,
>     1331)                                     &wait);
>     1332)          ahash_request_set_crypt(req, tsgl->sgl, result, vec->psize);
>     1333)          err = do_ahash_op(crypto_ahash_digest, req, &wait, cfg->nosimd);
>     1334)          if (err) {
> -> 1335)                  if (err == vec->digest_error)
>     1336)                          return 0;
>     1337)                  pr_err("alg: ahash: %s digest() failed on test vector %s; expected_error=%d, actual_error=%d, cfg=\"%s\"\n",
>     1338)                         driver, vec_name, vec->digest_error, err,
>     1339)                         cfg->name);
>     1340)                  return err;
>     1341)          }
>     1342)          if (vec->digest_error) {
>     1343)                  pr_err("alg: ahash: %s digest() unexpectedly succeeded on test vector %s; expected_error=%d, cfg=\"%s\"\n",
>     1344)                         driver, vec_name, vec->digest_error, cfg->name);
>     1345)                  return -EINVAL;
>     1346)          }
>     1347)          goto result_ready;
>     1348)  }
> 
> Seems that for some reason driver does not receive the interrupt from HW,
> thus completion callback does not run.
> 
> Tried with or without current patch series, no change in behaviour.
> 
> If you cannot reproduce and don't have any idea, I'll try the hard way
> (git bisect).

I cannot reproduce, both mpc885 and mpc8321e boot fine, and don't have 
any idea at first.

I know the SEC1 behaves that way when you submit zero-length data.

Christophe

> 
> Thanks,
> Horia
>