Re: [PATCH v3 6/8] tls: Flush backlog before tls_rx_rec_wait in read_sock

2026-03-11, 21:48:02 -0400, Chuck Lever wrote:
> From: Chuck Lever <[email protected]>
> 
> While lock_sock is held during read_sock, 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 until release_sock() drains it, forcing
> an extra workqueue cycle for records that arrive during
> decryption.
> 
> Calling sk_flush_backlog() before tls_rx_rec_wait() moves
> backlog data into sk_receive_queue, where tls_strp_check_rcv()
> can parse it immediately. The existing tls_read_flush_backlog
> call after decryption is retained for TCP window management.

I'm really confused by this.

 - Why is the existing tls_read_flush_backlog not enough?
   - and what is it still accomplishing now that we're flushing before
     every tls_rx_rec_wait?
 - Why are other RX paths not affected?

You first paragraph and the comment in the diff kind of say the
problem is that tls_rx_rec_wait() doesn't try to feed from the
backlog when sk_receive_queue is empty.

> @@ -2387,6 +2387,11 @@ int tls_sw_read_sock(struct sock *sk, read_descriptor_t *desc,
>  		} else {
>  			struct tls_decrypt_arg darg;
>  
> +			/* Drain backlog so segments that arrived while the
> +			 * lock was held appear on sk_receive_queue before
> +			 * tls_rx_rec_wait waits for a new record.
> +			 */
> +			sk_flush_backlog(sk);
>  			err = tls_rx_rec_wait(sk, NULL, true, released);
>  			if (err <= 0)
>  				goto read_sock_end;

-- 
Sabrina