Re: [PATCH 0/3] vmsplice: make vmsplice a trivial wrapper for preadv2/pwritev2
"David Hildenbrand (Arm)" <[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 | <[email protected]> |
On 5/31/26 10:54, Pedro Falcato wrote: > On Sun, May 31, 2026 at 01:01:04AM +0000, Askar Safin wrote: >> This patchset is for VFS. >> >> Recently we got a lot of vulnerabilities in splice/vmsplice. >> >> Also vmsplice already was source of vulnerabilities in the past: >> CVE-2020-29374 (see https://lwn.net/Articles/849638/ ). >> >> Also vmsplice is problematic for other reasons. Here is what other >> developers say: >> >> Linus Torvalds 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=iimyHyN8aessnbM9XQ9ufbaUz9g@mail.gmail.com/ >> >> Christoph Hellwig in May 2026: >>> vmsplice is the worst, as it is one of the few remaining places that >>> can incorrectly dirty file backed pages without telling the file system >>> and cause the other problems fixed by a FOLL_PIN conversion, but it is >>> the only one where we do not have any idea yet how we could convert it >>> to FOLL_PIN due to the unbounded pin time. >> https://lore.kernel.org/all/[email protected]/ >> >> See recent discussion here: >> https://lore.kernel.org/all/[email protected]/T/#u > > So, you took an ongoing discussion with an ongoing RFC patchset, and you > decided to reimplement part of the idea on your own, as a concurrent patchset. > > Riiiiiight.... I don't think I have to NAK this, do I? Jup. I'll just ignore this patch set here. -- Cheers, David