pespin has submitted this change. ( https://gerrit.osmocom.org/c/libosmocore/+/41671?usp=email )
Change subject: io_uring: RECVMSG_SENDMSG: Reset fd to blocking after osmo_fd_register() workaround
......................................................................
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.htmlhttps://github.com/axboe/liburing/issues/364
Change-Id: Idba623730230bc049b827e51b058cd64d23b730f
---
M src/core/osmo_io_uring.c
1 file changed, 22 insertions(+), 1 deletion(-)
Approvals:
daniel: Looks good to me, approved
Jenkins Builder: Verified
osmith: Looks good to me, but someone else must approve
diff --git a/src/core/osmo_io_uring.c b/src/core/osmo_io_uring.c
index cac6272..0304375 100644
--- a/src/core/osmo_io_uring.c
+++ b/src/core/osmo_io_uring.c
@@ -34,6 +34,7 @@
#include <unistd.h>
#include <string.h>
#include <stdbool.h>
+#include <fcntl.h>
#include <errno.h>
#include <limits.h>
@@ -534,6 +535,23 @@
static void iofd_uring_write_enable(struct osmo_io_fd *iofd);
static void iofd_uring_read_enable(struct osmo_io_fd *iofd);
+/* make an FD blockig:
+ * osmo_fd_register(ofd) did set fd flag O_NONBLOCK previously. We don't
+ * want to keep the fd as O_NONBLOCK once we start using io_uring,
+ * otherwise we'd end up getting cqes with -EAGAIN; better let the kernel
+ * wait internally for the sqe to complete. */
+static int iofd_reset_fd_blocking(int fd)
+{
+ int flags;
+
+ /* make FD nonblocking */
+ flags = fcntl(fd, F_GETFL);
+ if (flags < 0)
+ return flags;
+ flags &= ~O_NONBLOCK;
+ flags = fcntl(fd, F_SETFL, flags);
+ return flags;
+}
/* called via osmocom poll/select main handling once outbound non-blocking connect() completes */
static int iofd_uring_connected_cb(struct osmo_fd *ofd, unsigned int what)
@@ -547,6 +565,7 @@
/* Unregister from poll/select handling. */
osmo_fd_unregister(ofd);
+ iofd_reset_fd_blocking(ofd->fd);
IOFD_FLAG_UNSET(iofd, IOFD_FLAG_NOTIFY_CONNECTED);
/* Notify the application about this via a zero-length write completion call-back. */
@@ -591,7 +610,8 @@
* Use a temporary osmo_fd which we can use to notify us once the connection is established
* or failed (indicated by FD becoming writable). This is needed as (at least for SCTP sockets)
* one cannot submit a zero-length writev/sendmsg in order to get notification when the socket
- * is writable.*/
+ * is writable.
+ * NOTE: osmo_fd_register() sets iofd->fd as O_NONBLOCK. */
if (IOFD_FLAG_ISSET(iofd, IOFD_FLAG_NOTIFY_CONNECTED)) {
osmo_fd_setup(&iofd->u.uring.connect_ofd, iofd->fd, OSMO_FD_WRITE,
iofd_uring_connected_cb, iofd, 0);
@@ -664,6 +684,7 @@
if (IOFD_FLAG_ISSET(iofd, IOFD_FLAG_NOTIFY_CONNECTED)) {
osmo_fd_unregister(&iofd->u.uring.connect_ofd);
+ iofd_reset_fd_blocking(iofd->u.uring.connect_ofd.fd);
IOFD_FLAG_UNSET(iofd, IOFD_FLAG_NOTIFY_CONNECTED);
}
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/41671?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: merged
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: Idba623730230bc049b827e51b058cd64d23b730f
Gerrit-Change-Number: 41671
Gerrit-PatchSet: 4
Gerrit-Owner: pespin <pespin(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: daniel <dwillmann(a)sysmocom.de>
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: jolly <andreas(a)eversberg.eu>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: osmith <osmith(a)sysmocom.de>
Gerrit-Reviewer: pespin <pespin(a)sysmocom.de>
lynxis lazus has uploaded this change for review. ( https://gerrit.osmocom.org/c/pysim/+/41687?usp=email )
Change subject: saip: calculate the number of records for LF and CY
......................................................................
saip: calculate the number of records for LF and CY
Some templates (e.g. for 5GS) define files which aren't completely defined.
5GS OPL5G: doesn't have a file size defined in the template,
but a record size.
Change-Id: I5ec1757d6852eb24d3662ec1c3fc88365e90a616
---
M pySim/esim/saip/__init__.py
1 file changed, 3 insertions(+), 0 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/pysim refs/changes/87/41687/1
diff --git a/pySim/esim/saip/__init__.py b/pySim/esim/saip/__init__.py
index 6ec8b23..978a52a 100644
--- a/pySim/esim/saip/__init__.py
+++ b/pySim/esim/saip/__init__.py
@@ -144,6 +144,9 @@
def file_size(self) -> Optional[int]:
"""Return the size of the file in bytes."""
if self.file_type in ['LF', 'CY']:
+ if self._file_size and self.nb_rec is None and self.rec_len:
+ self.nb_rec = self._file_size // self.rec_len
+
return self.nb_rec * self.rec_len
elif self.file_type in ['TR', 'BT']:
return self._file_size
--
To view, visit https://gerrit.osmocom.org/c/pysim/+/41687?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: newchange
Gerrit-Project: pysim
Gerrit-Branch: master
Gerrit-Change-Id: I5ec1757d6852eb24d3662ec1c3fc88365e90a616
Gerrit-Change-Number: 41687
Gerrit-PatchSet: 1
Gerrit-Owner: lynxis lazus <lynxis(a)fe80.eu>
Attention is currently required from: pespin.
fixeria has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/libosmocore/+/41685?usp=email )
Change subject: logging: change gsmtap target to use wqueue by default
......................................................................
Patch Set 1:
(1 comment)
File include/osmocom/core/logging.h:
https://gerrit.osmocom.org/c/libosmocore/+/41685/comment/d6b2f693_7f4641ce?… :
PS1, Line 356: bool ofd_wq_mode;
> this is breaking ABI. […]
It's used outside of libosmocore, so I am not going to touch it.
Shall I add an entry to TODO-RELEASE?
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/41685?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I9d8c953a5b467ce4396d2d20ca6fa72a749723c0
Gerrit-Change-Number: 41685
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 16 Dec 2025 13:29:48 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Attention is currently required from: pespin.
fixeria has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/libosmocore/+/41685?usp=email )
Change subject: logging: change gsmtap target to use wqueue by default
......................................................................
Patch Set 1:
(1 comment)
File src/vty/logging_vty.c:
https://gerrit.osmocom.org/c/libosmocore/+/41685/comment/b51d971e_7d41e010?… :
PS1, Line 1047: if (tgt->tgt_gsmtap.ofd_wq_mode)
> You don't need here the new field tgt->tgt_gsmtap.ofd_wq_mode: […]
I would do exactly that if `struct gsmtap_inst` were public, but it's not.
It's an opaque struct for us here and we cannot access its fields.
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/41685?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I9d8c953a5b467ce4396d2d20ca6fa72a749723c0
Gerrit-Change-Number: 41685
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 16 Dec 2025 13:25:17 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Attention is currently required from: fixeria.
pespin has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/libosmocore/+/41685?usp=email )
Change subject: logging: change gsmtap target to use wqueue by default
......................................................................
Patch Set 1:
(1 comment)
Commit Message:
https://gerrit.osmocom.org/c/libosmocore/+/41685/comment/048d35c2_ccf9e02c?… :
PS1, Line 12: target, which can also be blocking under some circumstances.
> which can also be blocking if UDP socket buffer becomes full.
"UDP socket send buffer"
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/41685?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I9d8c953a5b467ce4396d2d20ca6fa72a749723c0
Gerrit-Change-Number: 41685
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 16 Dec 2025 13:24:28 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Attention is currently required from: fixeria.
pespin has posted comments on this change by fixeria. ( https://gerrit.osmocom.org/c/libosmocore/+/41685?usp=email )
Change subject: logging: change gsmtap target to use wqueue by default
......................................................................
Patch Set 1:
(3 comments)
Commit Message:
https://gerrit.osmocom.org/c/libosmocore/+/41685/comment/184afbc5_ced71834?… :
PS1, Line 12: target, which can also be blocking under some circumstances.
which can also be blocking if UDP socket buffer becomes full.
File include/osmocom/core/logging.h:
https://gerrit.osmocom.org/c/libosmocore/+/41685/comment/ee83b3d6_0605adc1?… :
PS1, Line 356: bool ofd_wq_mode;
this is breaking ABI.Can you check if log_target struct is used anywhere outside of libosmocore? If not, we can move this struct to an internal header.
File src/vty/logging_vty.c:
https://gerrit.osmocom.org/c/libosmocore/+/41685/comment/b6247ed3_1873a50e?… :
PS1, Line 1047: if (tgt->tgt_gsmtap.ofd_wq_mode)
You don't need here the new field tgt->tgt_gsmtap.ofd_wq_mode:
if (!target->tgt_gsmtap.gsmtap_inst || target->tgt_gsmtap.gsmtap_inst->osmo_io_mode)
--
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/41685?usp=email
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings?usp=email
Gerrit-MessageType: comment
Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I9d8c953a5b467ce4396d2d20ca6fa72a749723c0
Gerrit-Change-Number: 41685
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 16 Dec 2025 13:19:47 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No