Re: [RFC PATCH 11/10] pipe: Add fsync() support [ver #2]

[Konstantin Khlebnikov]

On 03/11/2019 02.14, Andy Lutomirski wrote:
> On Sat, Nov 2, 2019 at 4:10 PM Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> > On Sat, Nov 2, 2019 at 4:02 PM Linus Torvalds
> > <torvalds@xxxxxxxxxxxxxxxxxxxx> 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