On Tue, Sep 24, 2024 at 09:30:39PM +0800, Herbert Xu wrote:
> On Tue, Sep 24, 2024 at 03:16:09PM +0530, Naresh Kamboju wrote:
> >
> > Warning log:
> > ----------
> > tst_test.c:1617: TINFO: Timeout per run is 0h 02m 30s
> > af_alg01.c:36: TFAIL: instantiated nested hmac algorithm ('hmac(hmac(md5))')!
> > tst_af_alg.c:46: TBROK: unexpected error binding AF_ALG socket to hash
> > algorithm 'hmac(hmac(md5))': EINVAL (22)
>
> This is expected. You need to fix the test to not treat this as an
> error.
>
So the error code changed from ENOENT to EINVAL. These particular LTP tests
(af_alg01 and af_alg03) could check for either ENOENT or EINVAL, and it would
preserve the main point of the tests.
I do feel that the previous error code, ENOENT, was more logical though. From
userspace's perspective, these invalid algorithms don't exist and don't need to
be treated any different from other algorithms that don't exist.
Has it been checked what else in userspace might need to be updated as a result
of this change?
Looking at libkcapi for example
(https://github.com/smuellerDD/libkcapi/blob/master/lib/kcapi.h#L125) it passes
the error code up and documents it as part of its API:
* @return 0 upon success;
* -ENOENT - algorithm not available;
* -EOPNOTSUPP - AF_ALG family not available;
* -EINVAL - accept syscall failed
* -ENOMEM - cipher handle cannot be allocated
*/
int kcapi_cipher_init(struct kcapi_handle **handle, const char *ciphername,
uint32_t flags);
So that is now wrong, as "algorithm not available" can now be either ENOENT or
EINVAL.
I don't really see the reason for this churn. The kernel commit which made this
change (795f85fca229) provides no explanation either.
- Eric
