Netdev List
 help / color / mirror / Atom feed
From: Rishikesh Jethwani <rjethwani@purestorage.com>
To: netdev@vger.kernel.org
Cc: John Fastabend <john.fastabend@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>,
	Sabrina Dubroca <sd@queasysnail.net>,
	Rishikesh Jethwani <rjethwani@purestorage.com>
Subject: [PATCH net 1/2] tls: device: fix record start in the tls_device_decrypted tracepoint
Date: Thu, 15 Oct 2026 14:11:34 -0600	[thread overview]
Message-ID: <20261015201135.2744031-2-rjethwani@purestorage.com> (raw)
In-Reply-To: <20261015201135.2744031-1-rjethwani@purestorage.com>

tls_device_decrypted() reports the TCP sequence of the record it is
classifying as tcp_sk(sk)->copied_seq - rxm->full_len. The original
strparser read every record out of the TCP receive queue before the TLS
layer looked at it, so copied_seq had already moved past the record.

The TLS-specific strparser leaves the record in the TCP receive queue in
its normal mode and only calls tcp_read_done() from
tls_strp_msg_consume(), after decryption. When the tracepoint fires,
copied_seq still points at the first byte of the record, and the
reported tcp_seq is one record length too low.

In copy mode (e.g. when the receive queue is short or the record spans
non-contiguous or mixed decrypted/undecrypted skbs), tcp_read_sock()
has already advanced copied_seq past the record. It can also consume a
FIN that ends the record's last skb, which adds one byte of sequence
space absent from the record length, so subtracting the length reports
a start one byte too high. copied_seq cannot tell whether a FIN was
consumed, so the start must be saved before the read.

Save the record start in the strparser when it enters copy mode, and
add tls_device_rx_rec_start() to return it, or copied_seq while the
record remains queued. tls_strp_msg_cow() also enters copy mode, via
tcp_read_done(); save the start there too, so the saved value is valid
whenever copy_mode is set regardless of which path set it.

No functional change beyond the tracepoint argument.

Fixes: 84c61fe1a75b ("tls: rx: do not use the standard strparser")
Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com>
---
Tested on mlx5 (ConnectX-6 Dx) with TLS RX device offload: the
tls_device_decrypted tracepoint now reports the record's starting TCP
sequence. Also build-tested with CONFIG_TLS_DEVICE=n.

 include/net/tls.h    |  2 ++
 net/tls/tls_device.c | 17 ++++++++++++++++-
 net/tls/tls_strp.c   |  2 ++
 3 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/include/net/tls.h b/include/net/tls.h
index e57bef58851e..aebe21e8917d 100644
--- a/include/net/tls.h
+++ b/include/net/tls.h
@@ -123,6 +123,8 @@ struct tls_strparser {
 	bool msg_ready;
 
 	struct strp_msg stm;
+	/* TCP sequence of the record start, saved before entering copy mode. */
+	u32 copy_seq;
 
 	struct sk_buff *anchor;
 	struct work_struct work;
diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
index f11d0528fc43..33e6dc3d4164 100644
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -835,6 +835,21 @@ void tls_device_rx_resync_new_rec(struct sock *sk, u32 rcd_len, u32 seq)
 	tls_device_resync_rx(tls_ctx, sk, seq, rcd_sn);
 }
 
+/* TCP sequence of the first byte of the record the strparser holds. In
+ * normal mode the record stays in the TCP receive queue until
+ * tls_strp_msg_consume(), so copied_seq still points at its start. Copy
+ * mode saves the start before TCP reads advance copied_seq, possibly
+ * over a FIN that is not part of the record.
+ */
+static u32 tls_device_rx_rec_start(struct sock *sk,
+				   struct tls_sw_context_rx *sw_ctx)
+{
+	if (sw_ctx->strp.copy_mode)
+		return sw_ctx->strp.copy_seq;
+
+	return tcp_sk(sk)->copied_seq;
+}
+
 static void tls_device_core_ctrl_rx_resync(struct tls_context *tls_ctx,
 					   struct tls_offload_context_rx *ctx,
 					   struct sock *sk, struct sk_buff *skb)
@@ -990,7 +1005,7 @@ int tls_device_decrypted(struct sock *sk, struct tls_context *tls_ctx)
 		is_encrypted = 0;
 	}
 
-	trace_tls_device_decrypted(sk, tcp_sk(sk)->copied_seq - rxm->full_len,
+	trace_tls_device_decrypted(sk, tls_device_rx_rec_start(sk, sw_ctx),
 				   tls_ctx->rx.rec_seq, rxm->full_len,
 				   is_encrypted, is_decrypted);
 
diff --git a/net/tls/tls_strp.c b/net/tls/tls_strp.c
index 6cc222008d95..ad8b5150ac97 100644
--- a/net/tls/tls_strp.c
+++ b/net/tls/tls_strp.c
@@ -132,6 +132,7 @@ int tls_strp_msg_cow(struct tls_sw_context_rx *ctx)
 	tls_strp_anchor_free(strp);
 	strp->anchor = skb;
 
+	strp->copy_seq = tcp_sk(strp->sk)->copied_seq;
 	tcp_read_done(strp->sk, strp->stm.full_len);
 	strp->copy_mode = 1;
 
@@ -418,6 +419,7 @@ static int tls_strp_read_copy(struct tls_strparser *strp, bool qshort)
 
 	shinfo->frag_list = NULL;
 
+	strp->copy_seq = tcp_sk(strp->sk)->copied_seq;
 	strp->copy_mode = 1;
 	strp->stm.offset = 0;
 
-- 
2.50.1


  reply	other threads:[~2026-10-15 20:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 20:11 [PATCH net 0/2] tls: device: fix users of copied_seq after the strparser rework Rishikesh Jethwani
2026-10-15 20:11 ` Rishikesh Jethwani [this message]
2026-10-15 20:11 ` [PATCH net 2/2] tls: device: fix next-record sequence in core-driven RX resync Rishikesh Jethwani
2026-10-15 20:14 ` [PATCH net 0/2] tls: device: fix users of copied_seq after the strparser rework netdev-bot+sinfo
2026-10-15 20:55   ` Rishikesh Jethwani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261015201135.2744031-2-rjethwani@purestorage.com \
    --to=rjethwani@purestorage.com \
    --cc=john.fastabend@gmail.com \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sd@queasysnail.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox