[PATCH net 0/2] tls: device: fix users of copied_seq after the strparser rework

Since commit 84c61fe1a75b ("tls: rx: do not use the standard
strparser"), the record being processed stays in the TCP receive queue
in the strparser's normal mode, so tcp_sk(sk)->copied_seq points at the
start of the current record rather than past it. In copy mode it is past
the record, plus one if TCP consumed a FIN with it.

Two users in tls_device.c still assume the old meaning:

Patch 1 fixes the record start reported by the tls_device_decrypted
tracepoint. It saves the record start when the strparser enters copy
mode and adds tls_device_rx_rec_start() to return it.

Patch 2 uses that helper to fix the next-record TCP sequence passed to
the device by core-driven RX resync (TLS_OFFLOAD_SYNC_TYPE_CORE_NEXT_HINT,
used only by nfp). In normal mode the device was told that the next
record starts where the current one does.

Patch 1 was tested on mlx5. Patch 2 is untested on hardware; review of
the device-side effect from anyone with nfp kTLS RX would be welcome.

Rishikesh Jethwani (2):
  tls: device: fix record start in the tls_device_decrypted tracepoint
  tls: device: fix next-record sequence in core-driven RX resync

 include/net/tls.h    |  2 ++
 net/tls/tls_device.c | 24 +++++++++++++++++++++---
 net/tls/tls_strp.c   |  2 ++
 3 files changed, 25 insertions(+), 3 deletions(-)

-- 
2.50.1