Re: [PATCH v3 2/8] tls: Factor tls_rx_decrypt_record() helper

On 3/16/26 11:20, Sabrina Dubroca wrote:
> 2026-03-11, 21:47:58 -0400, Chuck Lever wrote:
>> From: Chuck Lever <[email protected]>
>>
>> recvmsg, read_sock, and splice_read each open-code the
>> same sequence: zero-initialize the decrypt arguments, call
>> tls_rx_one_record(), and abort the connection on failure.
>>
>> Extract tls_rx_decrypt_record() so each receive path shares
>> a single decrypt-and-abort primitive. Each call site still
>> initializes darg.inargs separately, since recvmsg sets zc
>> and async between the memset and the decrypt call.
> 
> Is there any reason to keep tls_rx_one_record()? You're replacing all
> existing callers, and not introducing new users in this series. Seems
> like what you want is just move the tls_err_abort() into
> tls_rx_one_record().
> 
> (I'm not convinced that "abort the connection on every error (decrypt
> fail or ENOMEM or whatever)" is right, but that's a separate question)
> 
It certainly is the sane option. Any error should be considered a
transmission error, so something has happened during transmission.
As the main point of TLS is transmission security, we cannot assume
anything (like being able to pick up the existing connection again),
and have to drop the connection to re-establish the security context.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke                  Kernel Storage Architect
[email protected]                                +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich