Re: [PATCH 0/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2
Linus Torvalds <[email protected]>
| Newsgroups | org.kernel.vger.linux-api,dev.linux.lists.patches,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.netdev,org.kvack.linux-mm |
|---|---|
| Message-ID | <CAHk-=wifX_rrDjRGnDnOqE-usptAukuXKrmuPuVDP5bOCBWzGQ@mail.gmail.com> |
On Mon, 1 Jun 2026 at 09:42, Christian Brauner <[email protected]> wrote: > > Applied to the vfs-7.2.vmsplice branch of the vfs/vfs.git tree. Btw, if people want to work further on this - assuming we don't get any huge screams of pain from having effectively gotten rid of vmsplice() - I don't think it would hurt to look at limiting the "regular" splice() too. We already have the code to just turn it into a pure copy on the "splice to pipe" case: copy_splice_read(). In many ways it would be *lovely* to just always force that path. We already do that explicitly for DAX and O_DIRECT, but we made a lot of special files do it implicitly too, so quite a lot of the splice reading cases already use that "just read() into a kernel space buffer" model for splicing. It would be interesting to hear who would even notice if we just always used that copy case, and made "f_op->splice_read" never trigger at all. And it turns out that the only thing that ever uses "f_op->splice_write" is splice_to_socket. Which was actually the problematic buggy case. Everybody else pretty much seems to just use iter_file_splice_write(), which does the "emulate it with just a write from kernel buffers". So *if* we get rid of f_op->splice_read, we do leave the case that really caused problems, but nobody will ever care. Because once splice only deals with private buffers that can't be shared with anything else, a f_op->splice_write() that gets things wrong is pretty much a non-event. (We'd have to look at 'tee()' too: I don't think anybody really uses it, but it does do the "no copy linking" by just incrementing refcounts on the pipe buffers. So to really protect against splice_write users messing up, that should do copies too, but as long as it's all "private ephemeral buffers" that get their refcounts updated, I don't think anybody *really* cares) TLDR: maybe we could ghet rid of "f_op->splice_read". *That* would be a big simplification. Linus