From patchwork Wed May 31 12:45:23 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Howells X-Patchwork-Id: 13262145 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 467D6C77B7A for ; Wed, 31 May 2023 12:45:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BB3528E0007; Wed, 31 May 2023 08:45:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B63C28E0002; Wed, 31 May 2023 08:45:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A041A8E0007; Wed, 31 May 2023 08:45:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 8D2E68E0002 for ; Wed, 31 May 2023 08:45:46 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 52F4540142 for ; Wed, 31 May 2023 12:45:46 +0000 (UTC) X-FDA: 80850521892.24.37FC9DF Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf11.hostedemail.com (Postfix) with ESMTP id 0A12F40013 for ; Wed, 31 May 2023 12:45:42 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=H5yRwNeV; spf=pass (imf11.hostedemail.com: domain of dhowells@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1685537143; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=VUrQef8DmIGGqxD5N5RNkU1BHyTMou9oFGzjwHHlMuE=; b=40ZF2ni4mcGhols6TA6uzK/Xgbcp/rTaSWq0W8egmDeyq1NjuCPI+CVBifcnNv91vDnWO+ 0JUjHcEbkHckUzFzpeknSiR7SfD/1dOvHVmc0CmsyKUQ7PvdFkaUEYsDZZaQeaNQwD8AJV WxR7qkmH4EhdZuhzg/z4lZA0MnzUeMA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1685537143; a=rsa-sha256; cv=none; b=6tDBWjv/1fnl+BvHyzC13WdV0tFVvfgmoeQwp5UQ3ghrtkOiXLGfEr9LE+Y8O5ildMNCiF hmdJOh57v5Gx60gs8lpUeIbYZxTAGXyt/BpYqgCs19CtmP42ohmddrgDGG8ty9CC9XVxHV jxGe68Un/spJbhurD7Sgr1eiAmHjA0k= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=H5yRwNeV; spf=pass (imf11.hostedemail.com: domain of dhowells@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=dhowells@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1685537142; 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: in-reply-to:in-reply-to:references:references; bh=VUrQef8DmIGGqxD5N5RNkU1BHyTMou9oFGzjwHHlMuE=; b=H5yRwNeVIjOnlS5NbLxWGa6hsALP2DgsXpmWB5byNmH/bj/eNw71uz3bZdOwWFtI/nvJhU 5rWTUaAGkSL09UJIWE0YSaiDFR5GScNUu1OziMoAHBDYKBhVEbvvAVgAwEk2q4no7YnUE/ IN+QKUgcOkPNSI68si7CnfvicpooxVk= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-479-MLbnjYjsMtCMKcbnjqfptw-1; Wed, 31 May 2023 08:45:38 -0400 X-MC-Unique: MLbnjYjsMtCMKcbnjqfptw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DE0311C0150B; Wed, 31 May 2023 12:45:37 +0000 (UTC) Received: from warthog.procyon.org.uk (unknown [10.42.28.182]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1CF7F20296C8; Wed, 31 May 2023 12:45:34 +0000 (UTC) From: David Howells To: netdev@vger.kernel.org Cc: David Howells , Chuck Lever , Boris Pismenny , John Fastabend , Jakub Kicinski , "David S. Miller" , Eric Dumazet , Paolo Abeni , Willem de Bruijn , David Ahern , Matthew Wilcox , Jens Axboe , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christoph Hellwig , Linus Torvalds , Al Viro , Jan Kara , Jeff Layton , David Hildenbrand , Christian Brauner , linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org Subject: [PATCH net-next v2 1/6] splice, net: Fix MSG_MORE signalling in splice_direct_to_actor() Date: Wed, 31 May 2023 13:45:23 +0100 Message-ID: <20230531124528.699123-2-dhowells@redhat.com> In-Reply-To: <20230531124528.699123-1-dhowells@redhat.com> References: <20230531124528.699123-1-dhowells@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Stat-Signature: eqif73fwybh5nw6331k7amxjn3b751nk X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 0A12F40013 X-Rspam-User: X-HE-Tag: 1685537142-252207 X-HE-Meta: U2FsdGVkX1+e0YOS24H0En+yZ4E2Lql4NspP6gOnspmH9q/S2+T0I2pEsVfXxJy46gI5GJwgQClrfBIvxYxQuyqeAeL6nW1WMXAzoBvjjBv6X8d4EMOoV52fKTeCgIqNFJ58Ai/hUNmTUnH3bXQ4b/p3jb3VYgsFuJOGN1vmkavTNq7Rz9XfeBbY00i29m1yymu64QaY/OJO1yydTNozVqRhCkdyHnRafKRivXGIlFlr4v6muQGrfzMIK/r1xBY7I80kHv/+a4U0mZlT3znOLRdBrnXIcrBsZVGU81SxKpi8ZgRKG7XNK/8udQ6RMiYNmCor9aoxHWviMeE8CZOdOd9V7/bM7vLy4424czd9dHmikj9fWoOBs+SPZxS9I0dNl1GZNpOrruquXnCEEAXr3t8kSVtUpvmNh2ChPCNz2NB54i//RTwiW1Hko5re/HVxEuI1Ahk2ZGINJpw5vaEz7THSm19S9KKu7u5oW+MHYbAjq/kNc4vYRqWHb/ybfFizCXNsUaDemr40hZ90vBNvflblLBHWJGuIuBRb04jhwwT6ZENK36yC9ohrepF7/70dDGdsqRDv0xVTyxysXP/CKyupwshB1VZo5fkO+MIpjxbU+ZKf6d/szKJ6xt7uHIPTCyjRDbSBGgkSScuaZ8KNa8vjpkPYEzsfgunqVcyZpj2PI7bF4QcIW7E+kyo0Bi6XdMzwJZrcLYwF6cDw6kZlykVefp0jM2PvMnhfJybneKyhsebILZ3sLxWDPJfdV03Dq34waB7/+doExmrCg762elrbwNYAnyrmkN0lAy+Ri19liYVO8myde48BK7o+paZCpqbxMLakMdtljvZj7jEYuuYm+yoRF69RNVbH24VOKK8Lz/wOwGkjWbvmmJXDUg/qqBRlO/qJzgZ4YL0kh2xwDyiAvabODE7XZJ4BKqnCsSfIqcwtSkKRoy8eeSEn4j76jOnRqd3t1oeKRljeeYt ERFneYnn cOFT81xYZhviEtRsDzh4m3OMVdvJC4V5A+8StpsP6JTdm7LwYBYAz9l87m9MjQwDnNwRcuMBptq9Mm+xZo6Kb8nN3bn873yK3hFYAQ5wVfRki0xawGnC6GFDYUmaRp1GuQ+Rp5RXVAiQPS4RJfrP+pwVe1bDjfejH16jpp2Ns/tB7FvxU9mecdF9r9ijUQ55ps+rlqGgC5fRYfvvYgbGxB0Bmf0sbGlki207RXPb+/nEVfk4doF4vuXvi/70s6tkunlVZpb40HJFCj/xM/6mbMF18vBS5pSL3QDQjyHJXm6l9bANc548bamPzFoOkPa1p5NPAVU1TSMxkJUCee9u9aMKm9kGEGemd4Zo78SkmQ7SVrHxmlqPpJDHghUZ/DQBbtpdMYZvgnFHeMS1b6oGO7UX/v7OSv9giYlIxyfDe41Oo5BeAc4wQtlFrDukUHJaCMEpGnmkA3t7ae39pGK93cBUnE6Owh62725J/FvOVak5O0vFDHFVMS0pM7h1fmqJnT7Nw6rDZZ21Q4LHLseyLNp9V4DFazUdEL+QNDu7/SDq31U9nP+Yw+FE41y8X9fIDkZU5ufpdXPxUFCVUD2yLkjDdWa7lAr8T3ylK64qUORM3oxgJwWtRRSX0LjuvLeCG2XIuCuhULTL+6gxzLcl0HUN9o+hg1CpFloqYkqNKVbk6m/0fLzkqzlRmrIVLh2paI9ee0Nnr/tHEBxoK6VuXay2LNTAT9Jt0QMcXcFjWGTKg7POXBSvd79gs1yv/JT7rqIUhOaGppVSWrLwaKVZKbREPDvNePLdFAbyydD5e35w59YU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: splice_direct_to_actor() doesn't manage SPLICE_F_MORE correctly - and, as a result, incorrectly signals MSG_MORE when splicing to a socket. The problem happens when a short splice occurs because we got a short read due to hitting the EOF on a file. Because the length read (read_len) is less than the remaining size to be spliced (len), SPLICE_F_MORE is set. This causes MSG_MORE to be set by pipe_to_sendpage(), indicating to the network protocol that more data is to be expected. With the changes I want to make to switch from using sendpage to using sendmsg(MSG_SPLICE_PAGES), MSG_MORE needs to work properly. This was observed with the multi_chunk_sendfile tests in the tls kselftest program. Some of those tests would hang and time out when the last chunk of file was less than the sendfile request size. This has been observed before[1] and worked around in AF_TLS[2]. Fix this by checking to see if the source file is seekable if we get a short read and, if it is, checking to see if we hit the file size. This should also work for block devices. This won't help procfiles and suchlike as they're zero length files that can be read from[3]. To handle that, should splice make a zero-length call with SPLICE_F_MORE cleared (assuming it wasn't set by userspace via splice()) if it gets a zero-length read? Signed-off-by: David Howells cc: Jakub Kicinski cc: Jens Axboe cc: Christoph Hellwig cc: Linus Torvalds cc: Al Viro cc: Matthew Wilcox cc: Jan Kara cc: Jeff Layton cc: David Hildenbrand cc: Christian Brauner cc: Chuck Lever cc: Boris Pismenny cc: John Fastabend cc: Eric Dumazet cc: "David S. Miller" cc: Paolo Abeni cc: linux-fsdevel@vger.kernel.org cc: linux-block@vger.kernel.org cc: linux-mm@kvack.org cc: netdev@vger.kernel.org Link: https://lore.kernel.org/netdev/1591392508-14592-1-git-send-email-pooja.trivedi@stackpath.com/ [1] Link: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=d452d48b9f8b1a7f8152d33ef52cfd7fe1735b0a [2] Link: https://lore.kernel.org/r/CAHk-=wjDq5_wLWrapzFiJ3ZNn6aGFWeMJpAj5q+4z-Ok8DD9dA@mail.gmail.com/ [3] --- fs/splice.c | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/fs/splice.c b/fs/splice.c index 3e06611d19ae..a7cf216c02a7 100644 --- a/fs/splice.c +++ b/fs/splice.c @@ -982,10 +982,21 @@ ssize_t splice_direct_to_actor(struct file *in, struct splice_desc *sd, * If this is the last data and SPLICE_F_MORE was not set * initially, clears it. */ - if (read_len < len) - sd->flags |= SPLICE_F_MORE; - else if (!more) + if (read_len < len) { + struct inode *ii = in->f_mapping->host; + + if (ii->i_fop->llseek != noop_llseek && + pos >= i_size_read(ii)) { + if (!more) + sd->flags &= ~SPLICE_F_MORE; + } else { + sd->flags |= SPLICE_F_MORE; + } + + } else if (!more) { sd->flags &= ~SPLICE_F_MORE; + } + /* * NOTE: nonblocking mode only applies to the input. We * must not do the output in nonblocking mode as then we