[PATCH net 2/2] tls: device: fix next-record sequence in core-driven RX resync

[Rishikesh Jethwani <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. The device is pointed at the wrong record
boundary, so records keep being decrypted in software until a later
attempt, retried with exponential backoff, goes through the
parser-driven path instead.

In copy mode copied_seq is already past the record, so the hint 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_device_rx_rec_start() plus the record
length instead. That is the start of the next record in both modes, so
the hint no longer depends on which mode the strparser is in.

Only drivers using TLS_OFFLOAD_SYNC_TYPE_CORE_NEXT_HINT are affected.

Fixes: 84c61fe1a75b ("tls: rx: do not use the standard strparser")
Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com>
---
Not tested on nfp hardware; I do not have a NIC that uses
TLS_OFFLOAD_SYNC_TYPE_CORE_NEXT_HINT. The fix follows the contract in
Documentation/networking/tls-offload.rst ("informs the device about the
next expected record number and its TCP sequence number"). Build-tested
with CONFIG_TLS_DEVICE=y and =n.

 net/tls/tls_device.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
index 33e6dc3d4164..7dfbead19d3e 100644
--- a/net/tls/tls_device.c
+++ b/net/tls/tls_device.c
@@ -854,6 +854,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 */
@@ -892,8 +893,10 @@ 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);
+		/* the next record starts right after the current one */
+		tls_device_resync_rx(tls_ctx, sk,
+				     tls_device_rx_rec_start(sk, sw_ctx) +
+				     rxm->full_len, rcd_sn);
 	}
 }
 
-- 
2.50.1