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=-2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 F251DCA9ED2 for ; Sun, 3 Nov 2019 12:02:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id CA7C1214D8 for ; Sun, 3 Nov 2019 12:02:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=yandex-team.ru header.i=@yandex-team.ru header.b="dSxNOPO6" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727425AbfKCMCM (ORCPT ); Sun, 3 Nov 2019 07:02:12 -0500 Received: from forwardcorp1p.mail.yandex.net ([77.88.29.217]:57400 "EHLO forwardcorp1p.mail.yandex.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726998AbfKCMCM (ORCPT ); Sun, 3 Nov 2019 07:02:12 -0500 Received: from mxbackcorp1j.mail.yandex.net (mxbackcorp1j.mail.yandex.net [IPv6:2a02:6b8:0:1619::162]) by forwardcorp1p.mail.yandex.net (Yandex) with ESMTP id 54FA82E12F1; Sun, 3 Nov 2019 15:02:07 +0300 (MSK) Received: from myt5-6212ef07a9ec.qloud-c.yandex.net (myt5-6212ef07a9ec.qloud-c.yandex.net [2a02:6b8:c12:3b2d:0:640:6212:ef07]) by mxbackcorp1j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id E9iTHkqXmn-25RCivqh; Sun, 03 Nov 2019 15:02:07 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1572782527; bh=22EDXIE7sdCqMg9/8WHEbWESicgc5h63XsjO5uxv1rM=; h=In-Reply-To:Message-ID:From:Date:References:To:Subject:Cc; b=dSxNOPO6KBTPwQVUMQsuoRYP2Rm4g+elu12lWUeOlbU6shBt2vVjk+8a9T+Ws1Crl 7M9I/RtuybtEgw/2CYq/3gOZp2rM6HlcFjEq+tAopJfR6tmmd46WeI5DCF7/o5oKNY gSw+yqWfMiXCpvTo7HcNlk9jNn8xHug4DNIN8o/8= Authentication-Results: mxbackcorp1j.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Received: from unknown (unknown [2a02:6b8:b080:7101::1:7]) by myt5-6212ef07a9ec.qloud-c.yandex.net (nwsmtp/Yandex) with ESMTPSA id 1UOEXN5iqJ-25VW2Fdc; Sun, 03 Nov 2019 15:02:05 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) Subject: Re: [RFC PATCH 11/10] pipe: Add fsync() support [ver #2] To: Andy Lutomirski , Linus Torvalds Cc: David Howells , 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 , Miklos Szeredi References: From: Konstantin Khlebnikov Message-ID: Date: Sun, 3 Nov 2019 15:02:05 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 7bit Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On 03/11/2019 02.14, Andy Lutomirski wrote: > 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. Looks monstrous. This will kill all fun and profit. =) I think vmsplice should at least deprecate and ignore SPLICE_F_GIFT. It almost never works - if page still mapped then page_count in generic_pipe_buf_steal() will be at least 2 (pte and pipe gup). But if user munmap vma between splicing and consuming (and page not stuck in lazy tlb and per-cpu vectors) then page from anon lru could be spliced into file. Ouch. And looks like fuse device still accepts SPLICE_F_MOVE. > > >> >> 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 > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konstantin Khlebnikov Date: Sun, 03 Nov 2019 12:02:05 +0000 Subject: Re: [RFC PATCH 11/10] pipe: Add fsync() support [ver #2] Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit List-Id: References: In-Reply-To: To: Andy Lutomirski , Linus Torvalds Cc: David Howells , 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 , Miklos Szeredi On 03/11/2019 02.14, Andy Lutomirski wrote: > 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. Looks monstrous. This will kill all fun and profit. =) I think vmsplice should at least deprecate and ignore SPLICE_F_GIFT. It almost never works - if page still mapped then page_count in generic_pipe_buf_steal() will be at least 2 (pte and pipe gup). But if user munmap vma between splicing and consuming (and page not stuck in lazy tlb and per-cpu vectors) then page from anon lru could be spliced into file. Ouch. And looks like fuse device still accepts SPLICE_F_MOVE. > > >> >> 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 >