Re: [PATCH 3/3] AF_ALG: Document that it is *always* slower

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The updated documentation incorrectly claims that AF_ALG no longer supports zero-copy and is always slower than userspace implementations.
--

commit f8743e2c044cc9e325ac113d7556afdf2c4c58d9
Author: Demi Marie Obenour <demiobenour@gmail.com>

AF_ALG: Document that it is *always* slower

This commit updates the userspace interface documentation to assert that
AF_ALG is always slower than software cryptography. It modifies the text
to state that zero-copy support has been completely removed from AF_ALG.

> diff --git a/Documentation/crypto/userspace-if.rst b/Documentation/crypto/userspace-if.rst
> index b31117d4415dd..ab93300c8e045 100644
> --- a/Documentation/crypto/userspace-if.rst
> +++ b/Documentation/crypto/userspace-if.rst

[ ... ]

> +Nowadays, AF_ALG no longer supports zero-copy or off-CPU accelerators.
> +Therefore, it is *always* slower than an optimized userspace implementation,
> +even for large messages. The only possible advantage left is that it avoids

[Severity: Medium]
Is this statement entirely accurate? While zero-copy was removed from aead and
skcipher, it appears to still be supported and functional for AF_ALG hash
algorithms in crypto/algif_hash.c via extract_iter_to_sg().

Because of this, using splice() with AF_ALG for hashing large files can avoid
user-space memory copies and still outperform userspace implementations. Does
this documentation need to be updated to reflect the remaining zero-copy hash
support?

> +duplicating code between kernel and userspace. However, userspace
> +implementations, especially hardware-accelerated ones, do not need to be large.
> +Just because OpenSSL is huge does not mean that all userspace cryptography
> +libraries are.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260523-af-alg-harden-v1-0-c76755c3a5c5@gmail.com?part=3