From: Rishikesh Jethwani <rjethwani@purestorage.com>
To: netdev@vger.kernel.org
Cc: Rishikesh Jethwani <rjethwani@purestorage.com>,
John Fastabend <john.fastabend@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
Sabrina Dubroca <sd@queasysnail.net>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
linux-kernel@vger.kernel.org
Subject: [PATCH net v2 2/4] tls: device: fix next-record sequence in core-driven RX resync
Date: Thu, 22 Oct 2026 16:14:58 -0600 [thread overview]
Message-ID: <20261022221732.1397620-3-rjethwani@purestorage.com> (raw)
In-Reply-To: <20261022221732.1397620-1-rjethwani@purestorage.com>
tls_device_core_ctrl_rx_resync() asks the device to resync at the next
record, passing rec_seq + 1 together with tcp_sk(sk)->copied_seq as that
record's TCP sequence. With the original strparser the current record
had already been read out of the TCP receive queue, so copied_seq was
the start of the next record.
The TLS-specific strparser leaves the record queued in its normal mode
until tls_strp_msg_consume(), so copied_seq is still the start of the
current record. The resync branch is taken when tcp_inq() does not
exceed the record length, i.e. typically when the current record is the
only data queued, and the device is told that record rec_seq + 1 begins
where record rec_seq begins. This can prevent hardware resynchronization
and keep subsequent records on the software decryption path. Further
resync attempts are made with backoff.
In copy mode copied_seq is already past the record, so the sequence is
correct there; the only exception is a FIN consumed along with the
record, after which no further record can follow.
Use the record start from tls_strp_msg_seq() plus the record length
instead. That is the start of the next record in both modes, so the
reported sequence no longer depends on which mode the strparser is in.
Only drivers using TLS_OFFLOAD_SYNC_TYPE_CORE_NEXT_HINT are affected.
Found by code inspection while working on TLS 1.3 hardware offload
support.
Fixes: 84c61fe1a75b ("tls: rx: do not use the standard strparser")
Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com>
---
net/tls/tls_device.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
index fbfe6ec3df04..a6c4d0cc54c7 100644
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -839,6 +839,7 @@ 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)
{
+ struct tls_sw_context_rx *sw_ctx = tls_sw_ctx_rx(tls_ctx);
struct strp_msg *rxm;
/* device will request resyncs by itself based on stream scan */
@@ -877,8 +878,9 @@ static void tls_device_core_ctrl_rx_resync(struct tls_context *tls_ctx,
memcpy(rcd_sn, tls_ctx->rx.rec_seq, prot->rec_seq_size);
tls_bigint_increment(rcd_sn, prot->rec_seq_size);
- tls_device_resync_rx(tls_ctx, sk, tcp_sk(sk)->copied_seq,
- rcd_sn);
+ tls_device_resync_rx(tls_ctx, sk,
+ tls_strp_msg_seq(sw_ctx) +
+ rxm->full_len, rcd_sn);
}
}
--
2.50.1
next prev parent reply other threads:[~2026-10-22 22:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 22:14 [PATCH net v2 0/4] tls: device: fix RX record start tracking after strparser rework Rishikesh Jethwani
2026-10-22 22:14 ` [PATCH net v2 1/4] tls: device: fix record start in the tls_device_decrypted tracepoint Rishikesh Jethwani
2026-10-22 22:14 ` Rishikesh Jethwani [this message]
2026-10-26 22:48 ` [PATCH net v2 2/4] tls: device: fix next-record sequence in core-driven RX resync netdev-bot+sashiko
2026-10-27 17:52 ` Rishikesh Jethwani
2026-10-22 22:14 ` [PATCH net v2 3/4] tls: device: fix record start reported to RX resync in copy mode Rishikesh Jethwani
2026-10-22 22:15 ` [PATCH net v2 4/4] tls: device: fix next-record queued checks in core-driven RX resync 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=20261022221732.1397620-3-rjethwani@purestorage.com \
--to=rjethwani@purestorage.com \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=horms@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--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