Re: [LTP] testcases/kernel/crypto/crypto_user02.c: fix hmac candidate probing

[linuxtestproject.agent@gmail.com]

Hi Frank,

On August 13, 2026, Frank Ranner wrote:
> testcases/kernel/crypto/crypto_user02.c: fix hmac candidate probing

> +		rc = tst_crypto_add_alg(ctx, &alg);
> +		if (rc != 0 && rc != -EEXIST)
> +			continue;
> +
> +		memset(&report, 0, sizeof(report));
> +		strcpy(report.cru_name, ALGORITHM_CANDIDATES[i]);
> +		if (tst_crypto_get_alg(ctx, &report) != 0)
>  			continue;
>  
>  		/* it also has to be deletable */
> +		rc = tst_crypto_del_alg(ctx, &report, 1000);

Could -EEXIST candidates be skipped here? If this result refers to an
already-registered, unused template instance, GETALG selects it and DELALG
removes global crypto state that the test did not create. Such instances
remain registered after their users release them and are deletable once the
reference count permits it, so cleanup does not restore the original state.

This can also leave another implementation with the same cru_name. The race
loop then gets -EEXIST from every NEWALG request, creates no larval, accepts
-ENOENT from the fixed-driver DELALG request, and falsely passes. Could setup
require successful creation rather than accepting an existing registration?

> Commit a4be708b4 ("try non-generic hmac names first") added a list of

Could this use c05a44cf instead? a4be708b4 does not resolve in the local LTP
history, while the Fixes tag identifies the same subject as c05a44cf.

Verdict - Needs revision

---
Note:

The agent can sometimes produce false positives although often its
findings are genuine. If you find issues with the review, please
comment this email or ignore the suggestions.

Regards,
LTP AI Reviewer

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp