Re: [PATCH net-next v12 6/6] tls: Flush backlog before waiting for a new record

[Sabrina Dubroca <sd@queasysnail.net>]

2026-06-04, 13:48:29 -0400, Chuck Lever wrote:
> From: Chuck Lever <chuck.lever@oracle.com>
> 
> While lock_sock is held, incoming TCP segments land on
> sk->sk_backlog rather than sk->sk_receive_queue.
> tls_rx_rec_wait() inspects only sk_receive_queue, so backlog
> data remains invisible. For non-blocking callers (read_sock,
> and recvmsg or splice_read with MSG_DONTWAIT) this causes a
> spurious -EAGAIN. For blocking callers it forces an
> unnecessary sleep/wakeup cycle.
> 
> Flush the backlog inside tls_rx_rec_wait() before checking
> sk_receive_queue so the strparser can parse newly-arrived
> segments immediately. On the next loop iteration
> tls_read_flush_backlog() may redundantly flush, but this
> path is cold and the cost is negligible.
> 
> Backlog processing can run tcp_reset(), which calls
> tcp_done_with_error() to set sk->sk_err = ECONNRESET and then
> tcp_done() to set sk->sk_shutdown = SHUTDOWN_MASK. The pre-existing
> top-of-loop sk_err check already ran before the flush, so the
> freshly-set error would be masked by the next-line sk_shutdown test
> returning 0 (EOF). Re-check sk_err immediately before the sk_shutdown
> test so a connection abort surfaces as -ECONNRESET rather than a clean
> EOF.
> 
> Commit f508262ae9f2 ("tls: Preserve sk_err across recvmsg() when
> data has been copied") gave the top-of-loop sk_err check a
> has_copied split. The recheck applies the same handling: when the
> caller has already copied bytes, sk_err is reported but preserved
> so the error surfaces on the next call; otherwise sock_error()
> consumes it so the error is reported exactly once.
> 
> Suggested-by: Sabrina Dubroca <sd@queasysnail.net>
> Link: https://lore.kernel.org/netdev/ahgHgQ84RCc8uYrG@krikkit/
> Reviewed-by: Hannes Reinecke <hare@suse.de>
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
>  net/tls/tls_sw.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)

Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>

Thanks for your patience with this series, Chuck.

-- 
Sabrina