Christian Brauner <[email protected]>: > Let's discuss the other aggressive alternative: Can we try and > unconditionally degrade to copy. This would affect sendfile(), splice(), > and vmsplice(). Worst-case we would have to introduce the sysctl > retroactively. > > Thoughts?
I think as a first step we should make vmsplice unconditionally equivalent to readv/writev. vmsplice already was problematic from security point of view long time ago. I mean CVE-2020-29374 (see https://lwn.net/Articles/849638/ ). David Howells also doesn't like vmsplice: https://lore.kernel.org/all/[email protected]/ Linus said in 2023: > So I'd personally be perfectly ok with just making vmsplice() be > exactly the same as write, and turn all of vmsplice() into just "it's > a read() if the pipe is open for read, and a write if it's open for > writing". https://lore.kernel.org/all/CAHk-=wgG_2cmHgZwKjydi7=iimyhyn8aessnbm9xq9ufbau...@mail.gmail.com/ Even experts get vmsplice wrong, as can be seen in this thread: https://lore.kernel.org/all/CAAUqJDvFuvms55Td1c=xkv6epfrnnp78438nzq-jkyucptg...@mail.gmail.com/T/#u As you can see in that thread, it is very hard to understand what vmsplice man page supposed to mean. And you can also see that vmsplice is very fragile. -- Askar Safin
