Re: [PATCH net 4/7] net: tls: fix off-by-one in sg_chain entry count for wrapped sk_msg ring
From: Sabrina Dubroca <sd@queasysnail.net>
Date: 2026-05-01 16:40:32
Also in:
bpf, linux-kselftest
[I'm slowly trying to catch up with the chunk of ktls patches that were posted in the past 3 days] 2026-04-29, 15:29:41 -0700, Jakub Kicinski wrote: [...]
Every other wrapped-ring arithmetic operation in the sk_msg subsystem (sk_msg_iter_dist, sk_msg_iter_var_next, sk_msg_iter_var_prev, bpf_msg_pull_data) correctly uses NR_MSG_FRAG_IDS as the ring modulus. This sg_chain call is the sole remaining use of MAX_SKB_FRAGS for ring-modulus arithmetic and was introduced after the ring expansion.
[...]
quoted hunk ↗ jump to hunk
diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index 906a1998c630..600e13effaab 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c@@ -802,7 +802,7 @@ static int tls_push_record(struct sock *sk, int flags, if (msg_pl->sg.end < msg_pl->sg.start) { sg_chain(&msg_pl->sg.data[msg_pl->sg.start], - MAX_SKB_FRAGS - msg_pl->sg.start + 1, + NR_MSG_FRAG_IDS - msg_pl->sg.start + 1, msg_pl->sg.data);
And get rid of the [start] / NR - start dance to make this code a bit clearer? This should maybe even be an skmsg helper to avoid "random" code making assumptions on the size of the sg.data array. The last paragraph in your commit message also tends to suggest that. -- Sabrina