Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp2712188pxv; Sun, 11 Jul 2021 23:31:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz0KtsTtBVOcpVVFMUuWP/Rie5VuC70RzdvF7TXSQdhfq2WM63F2rpwiGkcJ0XsFMEpy5Ww X-Received: by 2002:a05:6402:1c19:: with SMTP id ck25mr825376edb.128.1626071388438; Sun, 11 Jul 2021 23:29:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626071388; cv=none; d=google.com; s=arc-20160816; b=UqrHtp9k04horCqPmLP2XVM8G8ecX4Hw2iOqCWA9opjAmc6Zz4GbHbGtsOj0irjvNG o/4OFcSUYB3wfKfgtrQnvvPNvFXLRTwZezU2p+s/9pvduew21YXJVxAHpkbSR/o1bMod +L4sAXJztMzb5i1lKeDa/k2/CDY1jUD51yFMFd3vPurAyLZD/+YpcRZhxSrsjr4hel1j n2L6eBV07/8QMhscftM7+VoWRMYXcw67MUAEkeElARZxDtmYb3pgnhl9xFrc0cyAJ07K UFgiYYfQJDuK0uZKSIU7j/enSpSSdolqZYwuEfZck1PgjvGSWv9xsqzrj/KdFVYueNm1 3JKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=JxLu/JLXbQh3EFi/X5RQEmzwJb4PeHWLg52XQi3HBbY=; b=kD6EMSyAkmb2M9QNqikomTprD1gdrMK3uzub6VcedAasLarck0q81fX4dVSb82sO9h nX13bEGv4a5pBFncehZwHdU9G7X1THxTy1x7oM8xepHm1ywx9zjN89EdSwh0OIBkOywX mSx0vwc6ClSU/9xpb2cDnTHL9Pm/V+UUL+uxC2LdZOClx9fbYINyO5xV/fQZPqKCLpy5 V8mfHCKraf652p4K+pAKiRRiLgfkF98xD9NxLTs3+HD0qwcsuzFLGPs50THUrYHHzZhs dLVJqtBypKa6BPdvAsyADVO3AGH1XnY4VKgOf5Op0KNylE5Trr//wJnfMvYJ8fjA6vxy XTZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=KOTwvbyz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l27si1939464eja.265.2021.07.11.23.29.25; Sun, 11 Jul 2021 23:29:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=KOTwvbyz; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236506AbhGLGaP (ORCPT + 99 others); Mon, 12 Jul 2021 02:30:15 -0400 Received: from mail.kernel.org ([198.145.29.99]:47700 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234801AbhGLGZ6 (ORCPT ); Mon, 12 Jul 2021 02:25:58 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 9063361175; Mon, 12 Jul 2021 06:22:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1626070976; bh=+jnQwEwgY+JBGAUVJ2F9CXKCTXjX1MPPK7IxvWL91BY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=KOTwvbyzfrQw+vrwUDRBLfNWeH6OOxLGxGdLqr/gSbq7jy3XonoIyYp3Y0htNnwfW XsZEEZbW3By78IgVZgN0OKl7bfblskESH5u/A2eV82Uj49GBAsTz33i4+JpySh+5yJ x1JI0nne3wmGw78aQ9Dy+BdV9gSbRChkMfJXc7u0= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Vadim Fedorenko , Seth Forshee , Jakub Kicinski , "David S. Miller" , Sasha Levin Subject: [PATCH 5.4 222/348] tls: prevent oversized sendfile() hangs by ignoring MSG_MORE Date: Mon, 12 Jul 2021 08:10:06 +0200 Message-Id: <20210712060731.131670855@linuxfoundation.org> X-Mailer: git-send-email 2.32.0 In-Reply-To: <20210712060659.886176320@linuxfoundation.org> References: <20210712060659.886176320@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Jakub Kicinski [ Upstream commit d452d48b9f8b1a7f8152d33ef52cfd7fe1735b0a ] We got multiple reports that multi_chunk_sendfile test case from tls selftest fails. This was sort of expected, as the original fix was never applied (see it in the first Link:). The test in question uses sendfile() with count larger than the size of the underlying file. This will make splice set MSG_MORE on all sendpage calls, meaning TLS will never close and flush the last partial record. Eric seem to have addressed a similar problem in commit 35f9c09fe9c7 ("tcp: tcp_sendpages() should call tcp_push() once") by introducing MSG_SENDPAGE_NOTLAST. Unlike MSG_MORE MSG_SENDPAGE_NOTLAST is not set on the last call of a "pipefull" of data (PIPE_DEF_BUFFERS == 16, so every 16 pages or whenever we run out of data). Having a break every 16 pages should be fine, TLS can pack exactly 4 pages into a record, so for aligned reads there should be no difference, unaligned may see one extra record per sendpage(). Sticking to TCP semantics seems preferable to modifying splice, but we can revisit it if real life scenarios show a regression. Reported-by: Vadim Fedorenko Reported-by: Seth Forshee Link: https://lore.kernel.org/netdev/1591392508-14592-1-git-send-email-pooja.trivedi@stackpath.com/ Fixes: 3c4d7559159b ("tls: kernel TLS support") Signed-off-by: Jakub Kicinski Tested-by: Seth Forshee Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- net/tls/tls_sw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/tls/tls_sw.c b/net/tls/tls_sw.c index cdb65aa54be7..7fb5c067f429 100644 --- a/net/tls/tls_sw.c +++ b/net/tls/tls_sw.c @@ -1150,7 +1150,7 @@ static int tls_sw_do_sendpage(struct sock *sk, struct page *page, int ret = 0; bool eor; - eor = !(flags & (MSG_MORE | MSG_SENDPAGE_NOTLAST)); + eor = !(flags & MSG_SENDPAGE_NOTLAST); sk_clear_bit(SOCKWQ_ASYNC_NOSPACE, sk); /* Call the sk_stream functions to manage the sndbuf mem. */ -- 2.30.2