From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1970236165E; Mon, 11 May 2026 23:26:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778541977; cv=none; b=L9w7StYrTTQ2ess1ezdeJJpFDb+YR3Qs3g5R6xVLH/L8EHK3iI1tpkBIt+KVdsf75rPrbTCW6+9fP3gbP7opH/YqLxiDSeC5UKmFOVWJ4u6g1TANaCEA0yvsBUS4D1+/fL7IuMwutijsGlkpof8dr/iW/pIm3vyClZHfFhgM85Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778541977; c=relaxed/simple; bh=6QitpkQcyvOMV6v5rSbba5hwwrZ9rpupmnsSIon61ds=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:References: In-Reply-To:To:Cc; b=T4QFInRNhiKzNgOcXr5qcXw2rPtbveKznlZi+oC+7tNXqehHJfaw5NiwOpa31j6zW6jx1aiI6ZrDXm1MgYLl/tCpJI/id03yOCMAb2VVSHTTtPYwOo7P0gu1JDK5rGq9DehVamWfBYkwzoHWxdDPqN0QxFT3UbcSoSPGPrr4Svs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YB3Z3sv5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YB3Z3sv5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3AD26C2BCF7; Mon, 11 May 2026 23:26:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778541976; bh=6QitpkQcyvOMV6v5rSbba5hwwrZ9rpupmnsSIon61ds=; h=From:Date:Subject:References:In-Reply-To:To:Cc:From; b=YB3Z3sv5AEn2qlDvfaN/0LR60PluvFy10v9fk0UymZ3VLc+tgpRBtffDcJ/GM6Hnv CeNgmPdcIPMlY/s+4F21NZPiiKKGohbgGG/U9P48xXo+OZVNWwk7RNoOmZ4P81b/pw 39E9fEpHb0820eW5krKmYh4JtLeGeMz++5cul/iXTVv6fxzRyhKb/HhmtCD8UY94hN DQZTrda40+OsCslIe8TbTlgltAApiCjy7sR8DLJ+M3bRf7V7KSLuN3525vz6nmeQ8F LjwuuztfBBdMelxAJ7s+DXhydrsCioCqqEfHX/Dch8T5REFAJeArdjjdtFkcItJr5v K8dtvE7wHpjuA== From: Chuck Lever Date: Mon, 11 May 2026 19:25:57 -0400 Subject: [PATCH net-next v10 6/7] tls: Flush backlog before waiting for a new record Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20260511-tls-read-sock-v10-6-279fc5015f0e@oracle.com> References: <20260511-tls-read-sock-v10-0-279fc5015f0e@oracle.com> In-Reply-To: <20260511-tls-read-sock-v10-0-279fc5015f0e@oracle.com> To: John Fastabend , Jakub Kicinski , Sabrina Dubroca Cc: Eric Dumazet , Simon Horman , Paolo Abeni , netdev@vger.kernel.org, kernel-tls-handshake@lists.linux.dev, Chuck Lever , Hannes Reinecke X-Mailer: b4 0.16-dev-da966 X-Developer-Signature: v=1; a=openpgp-sha256; l=2282; i=chuck.lever@oracle.com; h=from:subject:message-id; bh=KaL64IKzNa/m6/MD4eXuqieu/IMKsc5ummh3EG9rnJs=; b=owEBbQKS/ZANAwAKATNqszNvZn+XAcsmYgBqAmWSG0VpAppw2NtXlSGKYkeWOfoL9MDTIM2Ul dL+CkI5QXqJAjMEAAEKAB0WIQQosuWwEobfJDzyPv4zarMzb2Z/lwUCagJlkgAKCRAzarMzb2Z/ lzHJD/9n88LDR3tQi47tHSDvCDWvTqc9OMesBYr51E2eknBhONLpdSpF0TXzfRcTIhl9nyWljKj 1L8UHniOy4b44AY00T9OiRGf79FoVFyl7U/dYEwziWYhj4uMnnz9gLdwHZxvIvTtXSdkJyT+OmN 72RK76Ws61RzWX+uwtN9WhZE8ewBxY6wRwbvj8Ar1C4jtlGV0AVTgL27s2WQDOSuvdyqWu+M5Rb CDxwTutO5emfj1BFcPtqdLnJF2i5NnORjxbxYXwrxNqLKNjraw0N+oYFcrLQIjkKr4JhTS1bzrI t6pUc16Qe+OFaKrGQJAwP9PgqTKtorPI+St8ysAIQJIvVN655rBWjTWoiYC36RfM/ioLj+u+2wT Hczi0/3WzivPONfeGYXUPjARnfT30QgNy6dHxtMSKS2Alii5f1z5r/d5ZcfZaminrZOI73FGkGt GxOkgMeCkeId2LDCfTxR9kY+YmFibwnWce1lcn3AqNwBH24XjR+p3T7/AjUVliFu1pRcDJKcTNe HeR7vLzDXq14Rlmnj4kOeMhPE7RuaVKjuq72ZpZ+nDfmsuDRtgu3PEGX8tezCQdphg2POmAJ0D1 Ykv55zamPK6Z8jd/llrMkX6TT7g1SEzDDxcSJJELBVHxQnMpsegaCzzU5KxtH/YEP//DhW85WZ9 HJRsc8t7HdDIWjg== X-Developer-Key: i=chuck.lever@oracle.com; a=openpgp; fpr=28B2E5B01286DF243CF23EFE336AB3336F667F97 From: Chuck Lever 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. Suggested-by: Sabrina Dubroca Reviewed-by: Hannes Reinecke Signed-off-by: Chuck Lever --- net/tls/tls_sw.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index 88d07199d5aa..2b7093d27eb6 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -1382,6 +1382,8 @@ tls_rx_rec_wait(struct sock *sk, struct sk_psock *psock, bool nonblock, if (ret < 0) return ret; + if (sk_flush_backlog(sk)) + released = true; if (!skb_queue_empty(&sk->sk_receive_queue)) { /* Defer notification to the exit point; this thread * will consume the record directly. @@ -1391,6 +1393,13 @@ tls_rx_rec_wait(struct sock *sk, struct sk_psock *psock, bool nonblock, break; } + /* sk_flush_backlog() can run tcp_reset(), which sets + * sk_err and then sk_shutdown via tcp_done(). Recheck + * sk_err here so a connection abort surfaces as the + * actual error rather than a clean EOF. + */ + if (sk->sk_err) + return sock_error(sk); if (sk->sk_shutdown & RCV_SHUTDOWN) return 0; -- 2.54.0