Re: [PATCH v8 5/6] tls: add hardware offload key update support

[Simon Horman <horms@kernel.org>]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.

For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
tls: add hardware offload key update support

Add TLS KeyUpdate (rekey) support for hardware offload connections.
When hardware rekey fails, the connection gracefully degrades to
software encryption/decryption while maintaining TLS_HW configuration.
Tested on Mellanox ConnectX-6 Dx (Crypto Enabled) with multiple
TLS 1.3 key update cycles.

> tls: add hardware offload key update support
>
> Add TLS KeyUpdate (rekey) support for hardware offload connections.
>
> When hardware rekey fails, the connection gracefully degrades to
> software encryption/decryption while maintaining TLS_HW configuration.

This commit message claims the connection "gracefully degrades to
software encryption/decryption" when hardware rekey fails. However,
the implementation appears inconsistent with this description.

Looking at the actual code behavior in net/tls/tls_main.c:

> @@ -711,64 +713,68 @@ static int do_tls_setsockopt_conf(struct sock *sk, sockptr_t optval,
>  	}
>
>  	if (tx) {
[ ... ]
> +		} else if (update && ctx->tx_conf == TLS_HW) {
> +			/* HW rekey failed - return the actual error.
> +			 * Cannot fall back to SW for an existing HW connection.
> +			 */
>  			goto err_crypto_info;

When hardware rekey fails on an existing TLS_HW TX connection, the code
returns an error rather than degrading to software mode. The same pattern
appears for RX:

[ ... ]
> +		} else if (update && ctx->rx_conf == TLS_HW) {
> +			/* HW rekey failed - return the actual error.
> +			 * Cannot fall back to SW for an existing HW connection.
> +			 */
>  			goto err_crypto_info;

The comments explicitly state "Cannot fall back to SW for an existing HW
connection." This contradicts the commit message's claim of graceful
degradation.

Could the commit message be updated to accurately describe the error
handling behavior? This inconsistency was noted by Sabrina Dubroca during
review of v7, and remains in v8:
https://lore.kernel.org/netdev/aZxm8hSrVMkEIc2O@krikkit/

Additionally, the commit message style may be worth reviewing. Sabrina
suggested looking through git log for net/ to match the typical commit
message format used in the networking subsystem.