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 B98FCC0015E for ; Thu, 20 Jul 2023 00:00:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F113B28009C; Wed, 19 Jul 2023 20:00:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E4C4328004C; Wed, 19 Jul 2023 20:00:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C9D7728009C; Wed, 19 Jul 2023 20:00:40 -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 B72E928004C for ; Wed, 19 Jul 2023 20:00:40 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 905A4A048B for ; Thu, 20 Jul 2023 00:00:40 +0000 (UTC) X-FDA: 81030033840.26.47BB2E0 Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) by imf10.hostedemail.com (Postfix) with ESMTP id 844B9C001C for ; Thu, 20 Jul 2023 00:00:38 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=NnlmABdl; spf=pass (imf10.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.49 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689811238; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=COIx9PJNSvI0bd/8+R1trZjf1/QUjd+w4gApApqhVyk=; b=qB12OosD77+miPC/TqtIezezlOkBrA4BnO19/OsQa0jT84d5iamHwKonD8Hy0bnCfk74Uy Wz9LGHmITmcFSqtHDSBSOB871bFsMGertniabHR0vNLTP2QR5YnVZqXFCRUST9pjbQqQM3 7jw3e6figbifmV9LoG8FIKeBpB80WDM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689811238; a=rsa-sha256; cv=none; b=kd+MdGytrCQP0zhSM7h1wVsnMJayOzwpX6q7ww9hm9y793oDEtr4wo1545ucJ7Ah+KA+gz 8dXSrRukoYnVioFaoPd9GLBzNq1wqahkjUzh0tO+6ApWv+LU9gPN9IyKt9PjTmTORkIsAq ZZarc18qtv5ixMOQSLqs7vGa+rBGDsA= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=NnlmABdl; spf=pass (imf10.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.49 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-ej1-f49.google.com with SMTP id a640c23a62f3a-98e39784a85so294042566b.1 for ; Wed, 19 Jul 2023 17:00:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1689811237; x=1692403237; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=COIx9PJNSvI0bd/8+R1trZjf1/QUjd+w4gApApqhVyk=; b=NnlmABdlgfcyYyH79U9UQWX+O0tKiipVmdb85nK2bSBM/aWDj7mfd5ylC1O1ykowNM dAl9apPj9FXotYDS1432ThAXZMYxNGpHTSbh9KsjkV0XmbZZyf7Y2IsAt+Fdr6OW9ABq 5ZVvc0YbfLwtACU4geOMBBYfD2Y89gX2Tgt4E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689811237; x=1692403237; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=COIx9PJNSvI0bd/8+R1trZjf1/QUjd+w4gApApqhVyk=; b=B0sdayBWGODpVYkT5jx9gsp2UJlzEkU4JpViZFwrFHckH3Tk5lA9vAvGmI6N4D2tUu iPI8ZTwyiLITcAJDMdzbM0GGN1eRIombB9O77OqIHkgliKET+yRdNJGFZ3xH7vtsFQJ1 eNPANXLTHlk+b5PexwTUh3EiHeZpTe1tE98b/2oLqYFFx/4fAmlMbheL7cD317SKHFCZ cMPHCXtq9stYGU+r5YDbB0sLidcdmXhox4jcjwMngvgSJn+bdOI9mobkOLz10w4ilFUG /58euwXMkhnR2SNmBCCuKk4mpu3dxd35G6UvXNnYd/ouMr8VW8fhx5VxdnlFhKUbhT57 Pfig== X-Gm-Message-State: ABy/qLbAlKLmQhissOVXSMVZTAWnkJX/zsiu/sIuezORvidLq9SCVr85 oluZwcVycJghuglUlnMalW7ATvru9PLlGdzyZkuIDSBB X-Google-Smtp-Source: APBJJlENLzEJSORNJdk7xgofI62c0Sx8xv9QidrtRbAPaNHwjnHBWywn+lgLrd99+K5N6goZ345zTQ== X-Received: by 2002:a17:907:7f13:b0:98e:738c:6d39 with SMTP id qf19-20020a1709077f1300b0098e738c6d39mr3625226ejc.36.1689811236894; Wed, 19 Jul 2023 17:00:36 -0700 (PDT) Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com. [209.85.208.41]) by smtp.gmail.com with ESMTPSA id y23-20020a17090668d700b00997cfef52fasm2979904ejr.94.2023.07.19.17.00.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Jul 2023 17:00:36 -0700 (PDT) Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-51a52a7d859so2924072a12.0 for ; Wed, 19 Jul 2023 17:00:34 -0700 (PDT) X-Received: by 2002:a50:fc13:0:b0:51d:914a:9f3d with SMTP id i19-20020a50fc13000000b0051d914a9f3dmr3806792edr.10.1689811234438; Wed, 19 Jul 2023 17:00:34 -0700 (PDT) MIME-Version: 1.0 References: <20230629155433.4170837-1-dhowells@redhat.com> <20230629155433.4170837-2-dhowells@redhat.com> <6609f1b8-3264-4017-ac3c-84a01ea12690@mattwhitlock.name> <0d10033a-7ea1-48e3-806b-f74000045915@mattwhitlock.name> In-Reply-To: <0d10033a-7ea1-48e3-806b-f74000045915@mattwhitlock.name> From: Linus Torvalds Date: Wed, 19 Jul 2023 17:00:17 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 1/4] splice: Fix corruption of spliced data after splice() returns To: Matt Whitlock Cc: Matthew Wilcox , Miklos Szeredi , David Howells , netdev@vger.kernel.org, Dave Chinner , Jens Axboe , linux-fsdevel@kvack.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christoph Hellwig , linux-fsdevel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: qxpuq6udsq461w1nei14r8u8xdz99eh5 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 844B9C001C X-Rspam-User: X-HE-Tag: 1689811238-28855 X-HE-Meta: U2FsdGVkX1+6HJqMMsrV57vOv++J2YCh3U3vPp5hXqRAJ2ilqA8ZyqHwij4x/ngLEVqSfDqzFAiTDnLSJ13ugxdBU3LoPBkvaBdOLWZl5BrhYd74eNAX5iPHRFZ5oqlH3+6dYlHZO+P+M5LDibW3mWKd0mNGBsg9jHfPXn2VGoNgfAEiLTkXRWdITKvbesZvlyWwz9YUHHAJGh/YM7b6X8dLEH1KSVnKt0yGKPNqpP7r7UcX9OnbU6CxCjySBv3NjJOGCv3l8OTd7lSK04eTxfP6s+IwYJWblabmnagC1h27z9sLqfbbslCnJUfUw3EPSHM5jodyUmqlY9uEDkvDcIEmpgdmc9Uwwd1DOydIm9Ixcm3CsADYUPbWOdLzxvMo1gMUPB1RlpJcLyPSYm/wDnbLck+gs78mb5WPkBdbeUk4pwRh3KjPjZKAYDM/kYmoJB4TSRc1POxQ7DeqxPcd20eRfGktz392dS9uA9CVYcCb3PnhlnDzZPnIHVgzcTZ5JUSye4cFEhL66UoKBKZScF2GXlX5usO+kKbxktgqTn6zS0yk4wxfpbQcbDSkNdcUqopswD+NRncmlsDjHk0154M+vODBzxL5cKIDZigbXDWxcMQNIBYBdqBmnWviNf+JPgtNu2MrVfuoPnPtmO8BIc0KdXzBusgi2XTias3oZx4ro+GlBVk4PsDdDHrNgUfOlmYq8RD4LVQkcO8+Hc9laQWVL0qskPp0Y0X1432XkWsfbDpm711gQsVPdN3rt6sFMUq03JKZTnYMogk3fHXKqOWUTNMCkWPtNwBPg2U2Qs+12C1wSiUCNQigDiYAzK/gyHdlMBDjzT6GyrJV2f3TXZ4oJhUCUEfDHmAZcQv4KLFWx3kNvXuDnRngbTtUjFKl3U1WEauAP+CLy8boynscaCsn2T4lEZze4+FolgwqjI932g7LYW9KGq70nlPWbZx+3Tzrt+HTJMyo+oGl+xp A6IWPVx9 1/fYw4Zip9aSooEb3zy4vu9xucq7MmGZMOIS2D0KVXU32DBbEaCe0/fAj81U3NhiBwldwQRRgeErNA2u1xSWTg2F4yZ17sgf27G745udkZNN0vycgX9miAW72nlnTd3MzG1psM8ilWFCRvOZ5Spsbal5cbYjJF4+S2G4JwddIZGB3ClytgQVYBFJZQkSj/j6DZB8jX7F8GN9Kt2Ajm23w318EsTXRXvKnx3QLArhUcje/SwPk2/nMtigKtRh6xfmv4tEB2ubNIhYMLsSeyo3ThsT08Yp1YScoI2TEA2BOQ5NW1eQbHHaAzk7IzxtErw0eqTBOF9uLThNCTniCmhG0ZPlsqdCQ6Y/JR0qUXUsn/TYeKLf3FE93CMBHRxYsgqevFi3UFZldlvlGXLHOH+MxXZfdjYQffIJaq7AeCEVgGWbhmimbwn9BdDvtQrZJtap7kvPHg3+x0ABBKUcjr70EWgkVOw== 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 Wed, 19 Jul 2023 at 16:41, Matt Whitlock wrote: > > Then that is my request. This entire complaint/discussion/argument would > have been avoided if splice(2) had contained a sentence like this one from > sendfile(2): > > "If out_fd refers to a socket or pipe with zero-copy support, callers must > ensure the transferred portions of the file referred to by in_fd remain > unmodified until the reader on the other end of out_fd has consumed the > transferred data." > > That is a clear warning of the perils of the implementation under the hood, > and it could/should be copied, more or less verbatim, to splice(2). Ack. Internally in the kernel, the two really have always been more or less of intermingled. In fact, I think splice()/sendfile()/tee() could - and maybe should - actually be a single man-page to make it clear that they are all facets of the same thing. The issues with TCP_CORK exist for splice too, for example, for exactly the same reasons. And while SPLICE_F_MORE exists, it only deals with multiple splice() calls, it doesn't deal with the "I wrote a header before I even started using splice()" case that is the one that is mentioned for sendfile(). Or course, technically TCP_CORK exists for plain write() use as well, but there the portable and historical fix is simply to use writev() and send it all in one go. So it's hopefully only when you use sendfile() and splice() that you end up with "oh, but I have multiple different *kinds* of sources, and I want to cork things until I've dealt with them all". Linus