From mboxrd@z Thu Jan 1 00:00:00 1970 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 2A6FEC001DE for ; Wed, 19 Jul 2023 23:41:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B2086280064; Wed, 19 Jul 2023 19:41:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AA9A428004C; Wed, 19 Jul 2023 19:41:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 92357280064; Wed, 19 Jul 2023 19:41:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7C96928004C for ; Wed, 19 Jul 2023 19:41:21 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3F0301401D2 for ; Wed, 19 Jul 2023 23:41:21 +0000 (UTC) X-FDA: 81029985162.30.4282729 Received: from resdmta-c1p-023853.sys.comcast.net (resdmta-c1p-023853.sys.comcast.net [96.102.19.46]) by imf14.hostedemail.com (Postfix) with ESMTP id 86032100011 for ; Wed, 19 Jul 2023 23:41:18 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=comcastmailservice.net header.s=20211018a header.b=fGjDJJNv; dmarc=none; spf=pass (imf14.hostedemail.com: domain of kernel@mattwhitlock.name designates 96.102.19.46 as permitted sender) smtp.mailfrom=kernel@mattwhitlock.name ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689810078; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=D0Zxwoc5PyVtQd58yNNXz/EasT5elbjv8i+Mv7KlxLk=; b=r07WfwIRCUzODAgWIg8k3BChOCVw7spbzOarkzTvoVtsnOTk5oug7o6q818AkCxibt0v1q G3AFAplx3+DVSYAoNFnx0AmNcaF3yBhnYOhGX2svClmtVz6fLSeb27YcxIO35Io4/UdTu0 EoZsy1NRuiGExs8qInVMAQm3Vta6Ec8= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=comcastmailservice.net header.s=20211018a header.b=fGjDJJNv; dmarc=none; spf=pass (imf14.hostedemail.com: domain of kernel@mattwhitlock.name designates 96.102.19.46 as permitted sender) smtp.mailfrom=kernel@mattwhitlock.name ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689810078; a=rsa-sha256; cv=none; b=N14gTIshb2yINYMeV1h8dY3azg2vtNq07S2B8PC0TUXOXewDEz/Qfslb2eCI91m+pOYr1f 963ODTcv+Qf+oVt2QzUiQwoBS+JRylCVneo+igzFPwURSp2aaeEP23oiWjHaqbq/7xWjbP Vkm/augTEb0884WR0EQ2IyHsUlI+Sj4= Received: from resomta-c1p-023269.sys.comcast.net ([96.102.18.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resdmta-c1p-023853.sys.comcast.net with ESMTP id MC9TqmTsIhn8ZMGnFqwF5U; Wed, 19 Jul 2023 23:41:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20211018a; t=1689810077; bh=D0Zxwoc5PyVtQd58yNNXz/EasT5elbjv8i+Mv7KlxLk=; h=Received:Received:From:To:Subject:Date:MIME-Version:Message-ID: Content-Type:Xfinity-Spam-Result; b=fGjDJJNvQ1PKmnlqZ/mcKtRAUkCpFYg/WUB1RoqnUzvCxJdhuKJ9k+xMtizjKvRde 0+RnnR+GLkn/GjO7XzWX7yLR6P+W2YlH7Y/gC9NX9BKz0uK0BJIbg2fYRUnyDYD3fg pO1ZPO42mIsMwe7G0WQDGIfIn6ChyvY5+JaYZ/MjRGHqs7dFuN6UHdg9NR6STNqlpe Mb+zJDI7NcylEnMCbJiVK2I9+Wzr2tMzR08FtnqQRPZ5YUv6Tdg5bhBBpAdTZDtWiG 0c0bd7V66/v1f4CUh+P/VmkRVamnZTw8DmrYbAno+h7oz8XKJ/MbH2HfZBn9HfRz8Q 9me9bBpR5H0Ng== Received: from localhost ([IPv6:2601:18c:9082:afd:219:d1ff:fe75:dc2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 256/256 bits) (Client did not present a certificate) by resomta-c1p-023269.sys.comcast.net with ESMTPSA id MGn6q5Mwsf3EjMGn7qAANV; Wed, 19 Jul 2023 23:41:13 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit From: Matt Whitlock To: Linus Torvalds Cc: Matthew Wilcox , Miklos Szeredi , David Howells , , Dave Chinner , Jens Axboe , , , , Christoph Hellwig , Subject: Re: [RFC PATCH 1/4] splice: Fix corruption of spliced data after =?iso-8859-1?Q?splice()_returns?= Date: Wed, 19 Jul 2023 19:41:07 -0400 MIME-Version: 1.0 Message-ID: <0d10033a-7ea1-48e3-806b-f74000045915@mattwhitlock.name> In-Reply-To: References: <20230629155433.4170837-1-dhowells@redhat.com> <20230629155433.4170837-2-dhowells@redhat.com> <6609f1b8-3264-4017-ac3c-84a01ea12690@mattwhitlock.name> User-Agent: Trojita/v0.7-595-g7738cd47; Qt/5.15.10; xcb; Linux; Gentoo Linux Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 86032100011 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: guxeuwgo59p3ikbqi7u1yck1c97ge3xx X-HE-Tag: 1689810078-449592 X-HE-Meta: U2FsdGVkX1+j++Qwd7/SMR944vY1Msimox4s13YmhZAEpXfxPBnLfH+37vg5jkRrybLpK4g1cAuHP1lLGPrgavxKzyMZkkqXEg/EyIOeULQxk1ZUljhSkft/EPeaPWorD4nKOy4MdTtQFcRBaH7Jy3j1xpeeO5pOi1ZWZiXcgESXr8IB0oKcX4F8Q4rOmw8H/AYtimwMR+vytraitL1ohYnf7gDzKRDiT14AjoioQ71DX7Oa0JZsqZrwvXvCrgmTR7vpUuhzldO2g2gsEjipNNNe7sCGJ71sj2LVgiVw75s0a99AK4bvbyUUkH6M49g99i+KgzhbjbUC7YaN/OcNFyeE83MrluxVB/QvhRxpB2Ejjr9sNm0DLw3DqrmZBFAeC4MmhkeSk6+cZcRvn6Kl/si85k+xt3xIjbniEn9J1NUe/BxHwalKnM0eEG0CwRDnGgU5PVSuNNvR1L8AIoH4U7ScOx5DqGUny9Pfljqs5ko905eoBwxZ736H2GYCbyViyN2gu8NWJdlgCZY+tY7RhGmjZ5TdrpCSTyXKVTyF9znWo7Krh28Lyi94l+TIJOQ7erPE+cBPJtHAIF1DmnrZfzl+BtrGsLLJ74dM41ekONayZRjQf4MwM4w6UoT9SjGiDdIPsUKpfz9yh3RRb3ybdVKm93mJ2mUKpO1yOYDiPhaBZDlvXQouV219Crd7+0umyG+AuyFxNP/Sh54JN2L6t8t8DdtKid9vg0tOXnECasN8unMr7dCl7wmPlpdGwOrLly2+C4Ct+en9QdiI+KQVAYUI+ENy6xsRrSxmc79TMNY+2hoa5Pqosgk2F+EyLWwD8tkV25/vIlllEIbScSIqO01KegBsUAsGnXcc1jLoITjkfo6uwrCiFyqkIgj+TztfVip6MRIKpvHsL8sk8U9JlaXYoZms1Xx4WIIxbNwvBb4eojLjBpPV5ejz4WpgeZ+dLaBzi/L98s5cPmCoBe1 gnjQI+cK kH6lV4ju9+jc8YSf50eRIMJKvZ90MJ51/pvCuhtCNOaRtJAvLP7Z0uGMW2waPjHtlEIQ3kO72vHT/3nkb81IYTzTxNdgGUUz9szvQfqjr82XAzJxA0++kqXRrucDXw7s/5msjaMpdOSQdYxg4yhNeazQiAvd9qsk7pERxQRlbxQHSokN5VsQ4a2m5XdlbFSczcfcPHyB3oLAQAM8iMxW39e6MDZ4VM1rZgY+xsKmnvrLYoK+MymD8uInBFbUyMMYBFuC07pLanDOdc56QeWtWbCW/4Jqh8h/F/nDHy4CbaQgjFPhgIvw9+ciN+nsmDN1vNwreeN9F9hhYaxQToJ62/jPBqx3AbYK8wRCU/ZLEG8Qdz+2nBYFKFsSbrunm5zQwdQ5oCWuGbNZzGjcQZ1s0wz2M5A== 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: On Wednesday, 19 July 2023 19:20:32 EDT, Linus Torvalds wrote: >> On Wednesday, 19 July 2023 16:16:07 EDT, Linus Torvalds wrote: >>> The *ONLY* reason for splice() existing is for zero-copy. >>=20 >> The very first sentence of splice(2) reads: "splice() moves data between >> two file descriptors without copying between kernel address space and user= >> address space." Thus, it is not unreasonable to believe that the point of >> splice is to avoid copying between user-space and kernel-space. > > I'm not at all opposed to clarifying the documentation. Then that is my request. This entire complaint/discussion/argument would=20 have been avoided if splice(2) had contained a sentence like this one from=20= sendfile(2): "If out_fd refers to a socket or pipe with zero-copy support, callers must=20= ensure the transferred portions of the file referred to by in_fd remain=20 unmodified until the reader on the other end of out_fd has consumed the=20 transferred data." That is a clear warning of the perils of the implementation under the hood,=20= and it could/should be copied, more or less verbatim, to splice(2).