From patchwork Sat Jan 4 15:29:45 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Benjamin Coddington X-Patchwork-Id: 13926277 X-Patchwork-Delegate: kuba@kernel.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (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 A8A7A18FDAF for ; Sat, 4 Jan 2025 15:29:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736004596; cv=none; b=LS2saDs+ijzMzkr0gtqhig9qWZIIaNpVhbtBCvU5QjjlntQX8iEXusA/vXocTvWqicYUi38SVJwkc/1EzN9mlk1EL2lQKOhGqOVGif4QZrpB3xT3Yy0xZI1eiJXnKc6vAn15NUNpmY5+yLBQErdaLlo6y7Ry4CnUdieZPRLzSXc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736004596; c=relaxed/simple; bh=U57buj9G2siMfW2sXnigbwSKDilrkriOtcFdMRkwtZI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=RSWatT6VtionzpTU+s2yQFKEuOEZw4xw7ekkhiTu6WfTk5MFagto8N1qgvi5ctUVBKztcT1fTM6d+isaSZB6FVxm0B5iHqAcJajVu3aYJXrsODkZx/wqCyoyJKWh/jbQcBDfmiIn930Y7PkBIOuU/hMc/I4cFHxYNZ18KnpKMcw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=KrwksU5a; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="KrwksU5a" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736004593; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=5QfsSW0/w50mw5rP1A7sUS5Wbk8ld/K3Kku0dCFploI=; b=KrwksU5adGNJB4a/+RMV/8xPPbx6CLVkg+nwXTcmhiOZDG0mM0r07XTcTizUPKBn/794b/ RMErCbeOCLe8rRQ61nefjTHdhU4YEvxaoRZg+GKFlReQMMexs3E6703g4/cE9M/pRvJFZS 9Y7h1AxSh9wIGntD1vZRjIIR1dUXJo4= Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-397-jgxWK_AaP4-b5GuROFefkA-1; Sat, 04 Jan 2025 10:29:50 -0500 X-MC-Unique: jgxWK_AaP4-b5GuROFefkA-1 X-Mimecast-MFC-AGG-ID: jgxWK_AaP4-b5GuROFefkA Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id DBE0919560A5; Sat, 4 Jan 2025 15:29:48 +0000 (UTC) Received: from bcodding.csb.redhat.com (unknown [10.22.76.8]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 72002195608A; Sat, 4 Jan 2025 15:29:46 +0000 (UTC) From: Benjamin Coddington To: Boris Pismenny , John Fastabend , Jakub Kicinski , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman Cc: netdev@vger.kernel.org, linux-nfs@vger.kernel.org Subject: [PATCH] tls: Fix tls_sw_sendmsg error handling Date: Sat, 4 Jan 2025 10:29:45 -0500 Message-ID: <9594185559881679d81f071b181a10eb07cd079f.1736004079.git.bcodding@redhat.com> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 X-Patchwork-Delegate: kuba@kernel.org We've noticed that NFS can hang when using RPC over TLS on an unstable connection, and investigation shows that the RPC layer is stuck in a tight loop attempting to transmit, but forever getting -EBADMSG back from the underlying network. The loop begins when tcp_sendmsg_locked() returns -EPIPE to tls_tx_records(), but that error is converted to -EBADMSG when calling the socket's error reporting handler. Instead of converting errors from tcp_sendmsg_locked(), let's pass them along in this path. The RPC layer handles -EPIPE by reconnecting the transport, which prevents the endless attempts to transmit on a broken connection. Signed-off-by: Benjamin Coddington --- net/tls/tls_sw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) base-commit: 0bc21e701a6ffacfdde7f04f87d664d82e8a13bf diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index bbf26cc4f6ee..7bcc9b4408a2 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -458,7 +458,7 @@ int tls_tx_records(struct sock *sk, int flags) tx_err: if (rc < 0 && rc != -EAGAIN) - tls_err_abort(sk, -EBADMSG); + tls_err_abort(sk, rc); return rc; }