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.
