> On Nov 2, 2019, at 12:34 PM, David Howells <dhowells@xxxxxxxxxx> wrote: > > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > >>>> Similar synchronization is required for reusing memory after vmsplice()? >>>> I don't see other way how sender could safely change these pages. > > Actually, it's probably worse than that. If the output of the pipe gets teed > or spliced somewhere else, you still don't know when the vmspliced pages are > finished with. > > I sometimes wonder whether vmsplice should be disallowed or severely restricted. Even ignoring these usability issues, it makes me very uncomfortable that you can have some data queue up on a pipe, tee() it, and get *different* data in the original pipe and the teed copy because the sender used vmsplice and is messing with you. Add in the fact that it’s not obvious that vmsplice *can* be used correctly, and I’m wondering if we should just remove it or make it just do write() under the hood. I suppose the kernel could guarantee that it stops referring to the vmsplice source pages as soon as anything sees *or* tees the data. This way it would be, at least in principle, possible to say “hey, the pipe has consumed the first n vmspliced bytes, so I can reuse that memory”.
