Re: [RFC -next 00/10] Add ZC notifications to splice and sendfile

[Christoph Hellwig <hch@infradead.org>]

On Wed, Mar 19, 2025 at 10:45:22AM -0700, Joe Damato wrote:
> I don't disagree; I just don't know if app developers:
>   a.) know that this is possible to do, and
>   b.) know how to do it

So if you don't know that why do you even do the work?

> In general: it does seem a bit odd to me that there isn't a safe
> sendfile syscall in Linux that uses existing completion notification
> mechanisms.

Agreed.  Where the existing notification mechanism is called io_uring.

> Of course, I certainly agree that the error queue is a work around.
> But it works, app use it, and its fairly well known. I don't see any
> reason, other than historical context, why sendmsg can use this
> mechanism, splice can, but sendfile shouldn't?

Because sendmsg should never have done that it certainly should not
spread beyond purely socket specific syscalls.

> If you feel very strongly that this cannot be merged without
> dropping sendfile2 and only plumbing this through for splice, then
> I'll drop the sendfile2 syscall when I submit officially (probably
> next week?).

Splice should also not do "error queue notifications".  Nothing
new and certainly nothing outside of net/ should.

> I do feel pretty strongly that it's more likely apps would use
> sendfile2 and we'd have safer apps out in the wild. But, I could be
> wrong.

A purely synchronous sendfile that is safe is a good thing.  Spreading
non-standard out of band notifications is not.  How to build that
safe sendmsg is a good question, and a sendmsg2 might be a sane
option for that.  The important thing is that the underlying code
should use iocbs and ki_complete to notify I/O completion so that
all the existing infrastucture like io_uring and in-kernel callers
can reuse this.

Note that this also ties into the currently broken memory mamangement
in the networking code that directly messeѕ with page references
rather than notifying the caller about I/O completion.