[PATCH net v2 0/4] tls: device: fix RX record start tracking after 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. Several places in
tls_device.c still derive record positions from copied_seq, and the
copy-mode header parse reports a record start that ignores where the
record begins within the first skb.

Patch 1 makes the strparser save each record's TCP sequence when it
starts parsing the record, before anything can switch it to copy mode,
and adds tls_strp_msg_seq() to return it. It uses that to fix the record
start reported by the tls_device_decrypted tracepoint.

Patch 2 uses the 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 3 fixes the record start passed to tls_device_rx_resync_new_rec()
when the header is parsed in copy mode. It was the start of the first
queued skb rather than of the record, so DRIVER_REQ and
DRIVER_REQ_ASYNC resyncs could be missed and CORE_NEXT_HINT given a
wrong boundary. Commit 9466ef3ec972 ("tls: fix RX desync on overlapping
skbs") made this path more likely right around a loss of device sync.

Patch 4 fixes the checks that decide whether the next record is already
queued before a CORE_NEXT_HINT hint is sent. They used tcp_inq(), which
counts from copied_seq, and now count from the record start, so the
result no longer depends on how much of the record has been consumed.
These checks were already wrong with the original strparser, so this
patch fixes the commit that added them rather than the rework. It
depends on patches 1-3.

Testing:

tools/testing/selftests/net/tls passed 655/655 on each host over
loopback, covering TLS 1.2 and 1.3 with AES-GCM-128/256, AES-CCM
and ChaCha20-Poly1305. SM4 and ARIA variants were excluded as those
algorithms are not enabled in the test kernel configuration.

On two mlx5 hosts with TLS 1.2 AES-GCM RX offload, all 28 cases
(1,344 records) passed plaintext and sequence checks. 26 cases reached
hardware decryption, four of them after a DRIVER_REQ_ASYNC resync. In
the other two, offload was installed mid-record and later headers were
split after two bytes; the NIC never issued a resync request, so these
cases cover only the sequence argument, not recovery.

Patch 1: all 1,344 tracepoint record starts matched the TCP captures,
covering normal parsing, copy mode, and three records where the copy
also consumed a FIN.

Patch 3: in 192 copied-header calls the old expression would have
reported a wrong record start; the fixed argument matched the wire
sequence in each. Hardware recovery through one of these repaired
calls was not observed.

Patches 2 and 4: these affect only TLS_OFFLOAD_SYNC_TYPE_CORE_NEXT_HINT,
which mlx5 does not use, so they are verified by analysis only.
Review of the device-side effect from anyone with nfp kTLS RX would be
welcome.

Changes in v2:
- Save the record start whenever the strparser starts a new record
  instead of on entry to copy mode, and keep the tracking in the
  strparser; rename tls_device_rx_rec_start() to tls_strp_msg_seq()
  (Sabrina).
- Say in each commit message how the issue was found.
- Add patch 3 (record start reported to RX resync in copy mode) and
  patch 4 (next-record queued checks for CORE_NEXT_HINT).
- Expand hardware testing on mlx5 (28 cases, tracepoint and
  resync-argument checks) and add software selftest results.

v1: https://lore.kernel.org/netdev/20261015201135.2744031-1-rjethwani@purestorage.com/ (local)

Rishikesh Jethwani (4):
  tls: device: fix record start in the tls_device_decrypted tracepoint
  tls: device: fix next-record sequence in core-driven RX resync
  tls: device: fix record start reported to RX resync in copy mode
  tls: device: fix next-record queued checks in core-driven RX resync

 include/net/tls.h    |  2 ++
 net/tls/tls.h        |  6 ++++++
 net/tls/tls_device.c | 16 +++++++++-------
 net/tls/tls_strp.c   |  3 +++
 net/tls/tls_sw.c     |  2 +-
 5 files changed, 21 insertions(+), 8 deletions(-)

-- 
2.50.1