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 X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8FF98CA9ED0 for ; Sat, 2 Nov 2019 23:15:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6439B217D9 for ; Sat, 2 Nov 2019 23:15:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572736501; bh=REB5//Mg+2UUv5NMyr1MVdv8ocwrgYZM1pxYX5vl4iA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=FH3NwDgWuhtQeDBMU1XbKAtUIMflPPqhV3C1cHcBOqWbDSgI426m1V9TpJGiOu3hn MwQgntB2EyF+kVDNDAuXvzZduAuUVd8VoF7DqCBpNmuACCpTngbuZu42BdG7I7G6Wp KfsDK9H1a36c278XnhMhBAy4F9wEh4V0yWYtjAWk= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727394AbfKBXPA (ORCPT ); Sat, 2 Nov 2019 19:15:00 -0400 Received: from mail.kernel.org ([198.145.29.99]:42864 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727267AbfKBXO7 (ORCPT ); Sat, 2 Nov 2019 19:14:59 -0400 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 73ADE21855 for ; Sat, 2 Nov 2019 23:14:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1572736498; bh=REB5//Mg+2UUv5NMyr1MVdv8ocwrgYZM1pxYX5vl4iA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=M+eT3FUF2jmJ2jN5PXXRGK/Qoi8ZaXjyPmPt7vGC/lPRcyHAo5BCeJPPl7GT3D2vH NREFz1CxaWKh03aYRPcbilVCC8pb01tix6xuZj4C6avNOQWC+IPC73Ws8tLGiGWf+O me6ANt3XpP/7rESPToHqJsbo7vFYVaL+XK229Yrk= Received: by mail-wr1-f47.google.com with SMTP id a15so13097412wrf.9 for ; Sat, 02 Nov 2019 16:14:58 -0700 (PDT) X-Gm-Message-State: APjAAAWQaBHTl+GR+52RamnWNB5R4Z89h/Ma6wYepWmeN6fg2eij2GTE co25FfzLV1V8MrPPtwdmpeM3oam0lWv8RkhunerXkw== X-Google-Smtp-Source: APXvYqwiaT/TYsPpvX/nSDbageOpVx9vUfoOUY5rzyPCC92h+QcJ3qEjOCN+6nwzv7Sif3nKLVFkueWLU7OXFbCI5Iw= X-Received: by 2002:adf:f7d1:: with SMTP id a17mr16289603wrq.111.1572736496889; Sat, 02 Nov 2019 16:14:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Andy Lutomirski Date: Sat, 2 Nov 2019 16:14:45 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC PATCH 11/10] pipe: Add fsync() support [ver #2] To: Linus Torvalds Cc: David Howells , Konstantin Khlebnikov , Rasmus Villemoes , Greg Kroah-Hartman , Peter Zijlstra , Nicolas Dichtel , raven@themaw.net, Christian Brauner , keyrings@vger.kernel.org, USB list , linux-block , LSM List , linux-fsdevel , Linux API , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Nov 2, 2019 at 4:10 PM Linus Torvalds wrote: > > On Sat, Nov 2, 2019 at 4:02 PM Linus Torvalds > wrote: > > > > But I don't think anybody actually _did_ any of that. But that's > > basically the argument for the three splice operations: > > write/vmsplice/splice(). Which one you use depends on the lifetime and > > the source of your data. write() is obviously for the copy case (the > > source data might not be stable), while splice() is for the "data from > > another source", and vmsplace() is "data is from stable data in my > > vm". > > Btw, it's really worth noting that "splice()" and friends are from a > more happy-go-lucky time when we were experimenting with new > interfaces, and in a day and age when people thought that interfaces > like "sendpage()" and zero-copy and playing games with the VM was a > great thing to do. I suppose a nicer interface might be: madvise(buf, len, MADV_STABILIZE); (MADV_STABILIZE is an imaginary operation that write protects the memory a la fork() but without the copying part.) vmsplice_safer(fd, ...); Where vmsplice_safer() is like vmsplice, except that it only works on write-protected pages. If you vmsplice_safer() some memory and then write to the memory, the pipe keeps the old copy. But this can all be done with memfd and splice, too, I think. > > It turns out that VM games are almost always more expensive than just > copying the data in the first place, but hey, people didn't know that, > and zero-copy was seen a big deal. > > The reality is that almost nobody uses splice and vmsplice at all, and > they have been a much bigger headache than they are worth. If I could > go back in time and not do them, I would. But there have been a few > very special uses that seem to actually like the interfaces. > > But it's entirely possible that we should kill vmsplice() (likely by > just implementing the semantics as "write()") because it's not common > enough to have the complexity. I think this is the right choice. FWIW, the openssl vmsplice() call looks dubious, but I suspect it's okay because it's vmsplicing to a netlink socket, and the kernel code on the other end won't read the data after it returns a response. --Andy