On Thu, Jul 30, 2026, at 6:38 AM, Sabrina Dubroca wrote:
> 2026-07-26, 20:33:30 -0400, Chuck Lever wrote:
>> +/* TLS 1.2 and TLS 1.3 both permit a zero-length application_data
>> + * record as a traffic-analysis countermeasure (RFC 5246, Section
>> + * 6.2.1; RFC 8446, Section 5.1).
>> + */
>> +static bool tls_rx_empty_data_rec(int len, unsigned char control)
>> +{
>> + return !len && control == TLS_RECORD_TYPE_DATA;
>> +}
>
> I'm not convinced by this helper. The record type check is redundant
> for splice and read_sock, and it doesn't save much for recvmsg.
Agreed. v2 of the series will drop it.
> If we're going to keep it, I'd rather pass it the skb and fetch the
> length and record type directly in the helper
That doesn't work for recvmsg. The length has to be read before
tls_rx_rec_done(), because on the zero-copy path darg.skb is the
strparser anchor and that call releases it. The type it needs is the
accumulated control, not the skb's. So the three sites will have to
open-code it.
> I don't think we should be leaking mentions of the "anchor" outside of
> strp.c.
I will reword it.
> This looping (and the existing one in the other RX handlers) is making
> rcvtimeo a bit pointless AFAICT [...] Am I reading this wrong?
You are not. rcvtimeo is applied at the reader lock and again in
tls_rx_rec_wait(), and neither bounds the loop as a whole.
--
Chuck Lever
