sockets: provide sousrsend() that does socket specific error handling

[glebius]

Summary

Sockets have special handling for EPIPE on a write, that was spread out
into several places. Treating transient errors is also special - if
protocol is atomic, than we should ignore any changes to uio_resid, a
transient error means the write had completely failed (see d2b3a0ed31e).

• Provide sousrsend() that expects a valid uio, and leave sosend() for kernel consumers only. Do all special error handling right here.
• In dofilewrite() don't do special handling of error for DTYPE_SOCKET.
• For send(2), write(2) and aio_write(2) call into sousrsend() and remove error handling for kern_sendit(), soo_write() and soaio_process_job().

PR: 265087
Reported by: rz-rpi03 at h-ka.de

[markj]

sys/kern/sys_generic.c

567

The comment style is wrong.

sys/kern/sys_socket.c

148

aio_process_rw() uses fo_write() and then contains the duplicated error-squashing and SIGPIPE handling, with no special cases for sockets.

[glebius]

Ok, getting back to this revision after vacation...

sys/kern/sys_socket.c

148

aio_process_rw() uses fo_write() and then contains the duplicated error-squashing and SIGPIPE handling, with no special cases for sockets.

But aio_process_rw() is scheduled aio_queue_file() which isn't executed for sockets.

For sockets we use soo_aio_queue(). See vfs_aio.c:1706. The soo_aio_queue() would schedule job on socket buffer job list, not on global aio_jobs. It would also kick socket's taskqueue, not the taskqueue used for file aio.

[glebius]

Rebase

[markj]

There is still some code in sctp (sys_sctp_generic_sendmsg() and sys_sctp_generic_sendmsg_iov()) which also duplicates the special error handling. I'm not sure what to do about it if anything, it cannot trivially be converted to use sousrsend(). Maybe @tuexen has an idea?

sys/kern/sys_socket.c

148

Ok, I see. I was confused a bit by the comments above aio_process_rw(), but they are really referring to vnode types, not file types.

sys/kern/uipc_socket.c

1829

1871

There's some style inconsistency when testing flags, both !(f & flag) and (f & flag) == 0 are used. I think the latter is better, but we should stick to one style.

[glebius]

• Rebase on fresh head
• Use flags as suggested by Mark