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
>