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 CDB21EB64DD for ; Thu, 29 Jun 2023 18:34:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 036D08D0002; Thu, 29 Jun 2023 14:34:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F294D8D0001; Thu, 29 Jun 2023 14:34:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E18908D0002; Thu, 29 Jun 2023 14:34:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D20518D0001 for ; Thu, 29 Jun 2023 14:34:27 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 9052DC037C for ; Thu, 29 Jun 2023 18:34:27 +0000 (UTC) X-FDA: 80956635774.15.E13CD88 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 2ED8320024 for ; Thu, 29 Jun 2023 18:34:23 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=aEGaXNVY; dmarc=none; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688063665; 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=8G2XND6WYYBgieuCNXQSJ0h8yM1THsepfLIyxBzOQdM=; b=Ez7qo6pPNXmdoXZ7/ZlBrSwmcXCR1tjy5RmJIF2J8/Y8uTk/Zv+MbM7LY2CWpnWvMrePu4 uFmfg1BkRkBRx5qcgAeCfKi4gNWYUmLTzLGklisdkPR7ERXdFA8UfnQEwPh/FPrWBavlH7 Yyfk5Ds5Vp4x8PpCf8kCS5NcH+3BlXU= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=aEGaXNVY; dmarc=none; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688063665; a=rsa-sha256; cv=none; b=zIMK1MDBeOlMa2wcKoIQJAXuv/qIO0KSkHIZu0iy8ebHD8GmCNssmojHeY0W0Q4zDuypXZ 5/8w2pdUkn3tX/rh7Td3yL2+zCta9ll/M8WRJTc8QK7QKltAS3yj2m7msY4byhvHXztH6P hjd9ox9cE7FzyyP/FDRJaEvW1RNWxUg= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=8G2XND6WYYBgieuCNXQSJ0h8yM1THsepfLIyxBzOQdM=; b=aEGaXNVYMMI9ZJt0oeCDZ/svCc exHWLiuPiysn9Ks+cpi3DZ0bmBihjeD6UviXcMmED95/uIQexzmrUsT6URaqJxmwGPhEfSfN10JU2 vtqXW3boponYUK8F66mpxozNHAPMLFh5fSS5ctUaWPG71ptmqXYI1MjMWeaXPenxEapadwkQ3423W lMTDwe+8SgXWyR2aJNBeOulLYVSjjF/ywhBxoHzRHxDio0UWamQch2p7hwhXOtUYBR2FHuC9J4zjd oNw24Mpswj9X1UqbXTc30lJCwFib7tZPcak83APHLqU+siC8/MSa0rFZIadFLzUxy8lDtOLqmgg3l Xn51G4Lw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qEwT2-0054UW-Tl; Thu, 29 Jun 2023 18:34:08 +0000 Date: Thu, 29 Jun 2023 19:34:08 +0100 From: Matthew Wilcox To: Linus Torvalds Cc: Matt Whitlock , David Howells , netdev@vger.kernel.org, Dave Chinner , Jens Axboe , linux-fsdevel@kvack.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/4] splice: Fix corruption in data spliced to pipe Message-ID: References: <20230629155433.4170837-1-dhowells@redhat.com> <4bd92932-c9d2-4cc8-b730-24c749087e39@mattwhitlock.name> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Stat-Signature: rpzjp188z6867en7p1bts9n5wmw4ny73 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 2ED8320024 X-HE-Tag: 1688063663-583567 X-HE-Meta: U2FsdGVkX18EYrGiRDT/19KKmQbjQHLk2cj4t2eP3Yx8mfXBnenMu195u9dSlSzBvEW3g7OSB80VDplDFi6cIIQObG8UrEhAX9oQtRsFDncUDhrmRYOUuuRkNsb8kkps5jXWQYqpAtymgNQVSG6LiZqCi81W8ESr2lVlTABDPgMGkE1epGjVGfCEk+T6Vsx1yS7VYZ2P97+UJhaSLHGLyOcm0cYzSTCSW6ZFdIfeW5upknC9/7eyf3veEWBYSCp8Vy3OZ9HN84eYuMnjC3gK1pTPnCjyuxe8/eq7gy9rQ2Bk7S3V5JF/N9GxGnaBF9tCWV3k897E4YiHcRU90XkJKwPW5FVqijbC++8I7PExg9uQ6NRJXXYewrLt1oqtvK2jfl1Ni50tWYXAwF7X1dmfKTNrRen9jWlue0NDE0xF0g+N2hIXUmKzesF2fFcEvP3IC9Rh5s8mSxn1WRuCN4RZ/U1zTKFIwpTm4eHC1bOqeQhopg7BkaHUEgc5RQfKulw2cw++R8uMHjJ4REkqdgj5Zx30Ls2Q6cMbZHYv35QfHVmx0lam6LiSEvMiyGdGXmTaTZVG3yJ/yQtsk+iX+XtiWLcigoDBWGtNppnCa4rWc020tzJfUxG518CgDUyKy91Qm6UP/8pqboYxAT2XNaRGLWwCVyN57buuVjFrnkoi05N0dgdzAx0mC1x8r4/NMj5CWZm2Gqq2kHi42GdlEiyApJ2/yMkrrcG2/k2+13JGtx8eYY4SfkqKx3lLRg6WgGcgSHnfWcY3XnK1syVBkC496jbIWUg7pB6XOMgreh97et6n/vauemQyNZQ+4M8s0/+mcs2fL6Zy9cMZuFvDAxTBOjoMdZVWySG3ZvU6OzY2gnbvBYMUHc4T09z2nbfu+K24kEibSTaTNBHHpaW5GW4QcKzmVUEXemQzcYxAAsADlW+xk7tyLN1FveGUdyETzpLLO1TisZXZmh45si1B9Wb riMhh6Lj c6Bt33kXOPMITd5KP3LJ6y5dAUNhLhXthKgumdWD3VEGJUmtqJU84Ta/0sP5eQtUxPkn32sbVVvr6D5gXLvj7T7ZlmbV4d/YefGfL6/XoFvqKIMaHqx6Dmaj3OP3aTvxKzfMLPRs9FIQcoik= 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 Thu, Jun 29, 2023 at 11:19:36AM -0700, Linus Torvalds wrote: > On Thu, 29 Jun 2023 at 11:05, Matt Whitlock wrote: > > > > I don't know why SPLICE_F_MOVE is being ignored in this thread. Sure, maybe > > the way it has historically been implemented was only relevant when the > > input FD is a pipe, but that's not what the man page implies. You have the > > opportunity to make it actually do what it says on the tin. > > First off, when documentation and reality disagree, it's the > documentation that is garbage. > > Secondly, your point is literally moot, from what I can tell: > > SPLICE_F_MOVE > Unused for vmsplice(); see splice(2). > > that's the doc I see right now for "man vmsplice". > > There's no "implies" there. There's an actual big honking clear > statement at the top of the man-page saying that what you claim is > simply not even remotely true. > > Also, the reason SPLICE_F_MOVE is unused for vmsplice() is that > actually trying to move pages would involve having to *remove* them > from the VM source. And the TLB invalidation involved with that is > literally more expensive than the memory copy would be. I think David muddied the waters by talking about vmsplice(). The problem encountered is with splice() from the page cache. Reading the documentation, splice() moves data between two file descriptors without copying be‐ tween kernel address space and user address space. It transfers up to len bytes of data from the file descriptor fd_in to the file descriptor fd_out, where one of the file descriptors must refer to a pipe. The bug reported is actually with using FALLOC_FL_PUNCH_HOLE, but a simpler problem is: #define _GNU_SOURCE #include #include #include #define PAGE_SIZE 4096 int main(int argc, char **argv) { int fd = open(argv[1], O_RDWR | O_CREAT, 0644); err = ftruncate(fd, PAGE_SIZE); pwrite(fd, "old", 3, 0); splice(fd, NULL, 1, NULL, PAGE_SIZE, 0); pwrite(fd, "new", 3, 0); return 0; } That outputs "new". Should it? If so, the manpage is really wrong. It says the point of splice() is to remove the kernel-user-kernel copy, and notes that zerocopy might be happening, but that's an optimisation the user shouldn't notice.