Once tls_sw_recvmsg() has copied enough data to meet the receive low-water mark, the receive loop continues only while another record is ready. A zero-length application_data record is consumed without advancing len, so a peer that follows data with a stream of empty records keeps the reader in the loop. The reader does not get the data already copied until the stream stops or a signal is pending. The delay has not been reproduced.
Leave the receive loop at an empty record once the low-water mark is met. A reader that has copied nothing still reads empty records for as long as they arrive. Suggested-by: sashiko-bot <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Chuck Lever <[email protected]> --- net/tls/tls_sw.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index b7f3edf9828e..fd6f944ffd67 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -1937,6 +1937,12 @@ int tls_sw_recvmsg(struct sock *sk, /* An empty record still marks a boundary. */ msg->msg_flags |= MSG_EOR; + + /* Return data already copied instead of holding it + * through a run of empty records. + */ + if (decrypted + copied >= target) + break; continue; } -- 2.55.0
