On 5/31/26 10:54, Pedro Falcato wrote:

On Sun, May 31, 2026 at 01:01:04AM +0000, Askar Safin wrote:

quoted

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:

quoted

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/ (local)

Christoph Hellwig in May 2026:

quoted

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/agwFlBKvKytjURDO@infradead.org/ (local)

See recent discussion here:
https://lore.kernel.org/all/20260516182126.530498-1-pfalcato@suse.de/T/#u (local)

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