Re: [RFC net-next 2/7] net/mlx5e: kTLS, Resync TX fully after its WQEs were lost

[sashiko-bot@kernel.org]

> The driver tracks the TIS state of a kTLS TX connection in software:
> expected_seq is the TCP sequence that the TIS expects next, and
> crypto_info.rec_seq is the record sequence of the last posted static
> params. It assumes that the WQEs it posts for an skb execute, which does
> not always hold:
> - The skb is dropped after its kTLS WQEs were posted, or after
>   expected_seq was advanced past its data: a failed resync, or a DMA
>   mapping error of its SEND.
> - An SQ error flushes the pending WQEs.
> - Closing an SQ (channels reopen, TX timeout recovery, HTB leaf delete)
>   destroys its pending WQEs.
> 
> The TIS state is then off from the software state, and the next skb is
> not resynced:
> - An in-order skb is encrypted with a stale record state, corrupting the
> [ ... ]
> 
> Fixes: d2ead1f360e8 ("net/mlx5e: Add kTLS TX HW offload support")
> Reported-by: Rishikesh Jethwani <rjethwani@everpuredata.com>
> Closes: https://lore.kernel.org/netdev/CAKaoeS1hj9XuM7ojLBCjGA=EXc2M-b+eRjC2Sk=8L_8XYeJ18w@mail.gmail.com/
> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109114734.2087878-1-tariqt@nvidia.com?part=2