Understanding task_work and recvmsg with buffers about liburing HOT 2 CLOSED

This probably should've been two separate discussions raised, rather than a single issue...

DEFER_TASKRUN does not imply the same behavior as COOP_TASKRUN. For the latter, the task_work will be run for any transition back from the kernel to userspace. For DEFER_TASKRUN, it's only run when the task waits on completions, either by using one of the io_uring_wait_cqe() variants, or by calling io_uring_get_events(). I don't think the kernel will complain if you set COOP_TASKRUN with DEFER_TASKRUN, but it won't make a difference. The former refers to task_work that the kernel knows about (it's referenced off the task struct itself), while the latter is an io_uring private type of task_work that the kernel doesn't have any insight into.

For non-multishot receive, msg_control is delivered just like it is with a recvmsg(2) syscall. Multishot has to place the data somewhere else, or it would be overwritten by the next trigger of the receive. And since you can have many come in before you process them in the application, that would not work so well.

from liburing.

Closing this one, please open as a discussion if there are further questions.

from liburing.