Skip to content
Success

Changes

Summary

  1. io_uring: RECVMSG_SENDMSG: Reset fd to blocking after osmo_fd_register() (details)
Commit b972b5a3093d5fc3e13d0fec9fa3737dc93e1a5e by Pau Espin Pedrol
io_uring: RECVMSG_SENDMSG: Reset fd to blocking after osmo_fd_register() workaround

When IOFD_FLAG_NOTIFY_CONNECTED is requested by the user through
osmo_iofd_notify_connected(), a write_cb(0, NULL) callback is done
towards the user to notify the socket is connected.

In mode RECVMSG_SENDMSG, at least for SCTP sockets, according to comment
in iofd_uring_register() (see also OS#5751) we cannot do the write(0)
trick to get notifications, so instead we need to workaround by using a
temporary osmo_fd to poll() for write status.
To do so, we call osmo_fd_register(), which internally sets the fd as
non-blocking (O_NONBLOCK). However, this is becomes an undesired
behavior later on when connect happens and io_uring is used to
recvmsg/sendmsg, since that could cause sqes to be answered with -EAGAIN
cqes at the kernel isntead of keeping (blocking) them internally until
the transaction can be resolved. This seems was a "desired" or
"expected" behavior in older kernels according to public
discussions/tickets, but it seeems it changed over time (see eg. GH#364
below).

In summary, the conclusion seems to be: try to avoid as much as possible mixing
O_NONBLOCK with io_uring, as you may get totally unexpected/changing
behavior.

Hence, avoid keeping O_NONBLOCK for those sockets when moving back from
osmo_fd to io_uring.

See regarding related discussion on the expected behavior with io_uring and O_NONBLOCK:
https://www.spinics.net/lists/io-uring/msg04058.html
https://github.com/axboe/liburing/issues/364

Change-Id: Idba623730230bc049b827e51b058cd64d23b730f
The file was modifiedsrc/core/osmo_io_uring.c