aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2024-04-09add utils/osmo-gsm-sharkneels/wipNeels Hofmeyr3-0/+3596
Change-Id: Ifdfd261f776d9bf2bbfb0a584deac3e9a11bfe47
2024-04-09ctrl: counters: list all possible names in not-found responseNeels Hofmeyr1-2/+22
Change-Id: I5e1d6bb2059fef2304868f415e1d664f2cf5d091
2024-04-09test timestamp formatsNeels Hofmeyr1-0/+4
Change-Id: Ifb96e0af055c536cd3b14685812d8fd67d65cd2c
2024-04-09logging: test timestamp formatsNeels Hofmeyr2-0/+58
Show what timestamp formats we currently feature. Upcoming patch Icbd5192ea835e24b12fe057cc1ab56e9572d75c0 adds a new timestamp format. Change-Id: If3dbf3006a454d4e8a5c758e5c884e12c8bb1fc1
2024-04-09logging: add 'logging timezone (localtime|utc)'Neels Hofmeyr6-3/+83
Add ability to print logging timestamps in UTC. I want to test logging timestamps in vty transcript tests. To get deterministic timestamps, I can use osmo_gettimeofday_override(). However, so far we log in the server's local time zone: the dates printed after osmo_gettimeofday_override() still change according to the locally configured timezone -- not good for regression testing. For UTC, it is always the same. The intended use is for regression testing of timestamps, but maybe logging in UTC may be useful to some user out there, too. Change-Id: I7f868b47bf8f8dfcf85e735f490ae69b18111af4
2024-04-09logging: add timestamp fmt 'date' = 2018-01-16,01:44:34.681Neels Hofmeyr4-3/+12
Add 'date' to 'logging print timestamp (none|date|date-packed|ctime)' The idea is to have these date formats: date 2018-01-16,01:44:34.681 (new, "best" format) date-packed 20180116014434681 (current 'print extended-timestamp 1') ctime Sun Jan 1 01:44:34 2018 (current 'timestamp 1') Rationale: when reading log files, it can be important to see milliseconds precision on the timestamps. But the current extended-timestamp format lacks all separators, reading these manually is a pain. My eyes aren't good at counting digits, I keep getting the minutes, seconds and millis wrong and waste my time on every glance. So provide a new detailed timestamp format that is easier to read. Change-Id: Icbd5192ea835e24b12fe057cc1ab56e9572d75c0
2024-04-09test new timestamp vtyNeels Hofmeyr1-23/+47
Change-Id: Ie1021a67c6cabfaa077471a6fc2954b8e90b57f2
2024-04-09logging vty: add 'logging print timestamp', deprecate other timestamp cmdsNeels Hofmeyr5-18/+67
Deprecate previous logging timestamp config commands: logging timestamp (0|1) logging print extended-timestamp (0|1) Add new single timestamp configuration command: logging print timestamp (none|date-packed|ctime) Another format called 'date' is added in patch Icbd5192ea835e24b12fe057cc1ab56e9572d75c0. The idea is to have these date formats: date 2018-01-16,01:44:34.681 (new, "best" format) date-packed 20180116014434681 (current 'print extended-timestamp 1') ctime Sun Jan 1 01:44:34 2018 (current 'timestamp 1') Change-Id: I58c792dda3cbcf8618648ba4429c27fa398a9e15
2024-04-09logging: use enum to set timestamp formatNeels Hofmeyr13-55/+110
In preparation of adding a new timestamp format, refactor to use an enum to pick the timestamp style. Introduce log_set_print_timestamp2() to be able to pass an enum value directly (for future additions). Deprecate previous API of log_set_print_timestamp() and log_set_print_extended_timestamp(). Remove the old members of struct log_target members: - print_timestamp and - print_ext_timestamp (bool flags), instead add member - timestamp_format (enum). This is an API and ABI incompatibility. (An original patch version preserved the unused struct members, but code review suggested it makes more sense to drop them.) The old API functions log_set_print_timestamp() and log_set_print_extended_timestamp() still work, but setting log_set_print_*timestamp(0) changes its behavior: now passing zero to either of these functions sets LOG_TIMESTAMP_NONE, so it now always switches off all timestamps, instead of previously maybe going back to another timestamp depending on the other flag being set or not. Change-Id: I70ecee543c266df54191d3e86401466cd1a5c0a6
2024-04-09logging_vty.c: rename static functionNeels Hofmeyr1-4/+4
Rename 'logging_prnt_timestamp_cmd' to logging_timestamp_cmd to better match its VTY name: 'logging timestamp (0|1)' (An actual 'logging print timestamp' command will be added in subsequent patch I58c792dda3cbcf8618648ba4429c27fa398a9e15, so clarify.) Change-Id: I5a651e393bd438ea236659ed2c86188a8f9885d1
2024-04-09add API logging_vty_subsys_strip_leading_char()Neels Hofmeyr3-1/+24
Allow an application to use subsystem names without a leading 'D'. With this patch, a program can: - remove the 'D' from struct log_info_cat[] entries -- normally, the VTY would then strip the 'M' from "MAIN" and we'd get 'ain'. - call logging_vty_subsys_strip_leading_char(false) during startup -- hence the VTY does not strip anything, and we get 'main' on the VTY config. So this allows an application to remove the odd 'D' from category names, without any changes in any VTY configuration. Background: I am hacking on some project where I want logging subsys names without a leading 'D'. So I noticed that the cfg file has mangled category names. Change-Id: I5faedf7d6525d744a734ebe54c185fcc904f763e
2024-04-09formalize log subsys stripping for vtyNeels Hofmeyr4-5/+14
In osmocom, we historically have a leading 'D' in all of our logging subsystem names -- not only in the enum entry name, but also as the string in struct log_info_cat[]. As a result of this, our logging_vty code strips away the first character of each logging subsystem name. In the VTY, we don't enter 'dmain', but only 'main' -- the VTY strips the 'D' from "DMAIN". The intention is to make this stripping behavior optional in a subsequent patch. So far the code to do that is a magic "+ 1" thrown in here and there. Instead, introduce log_subsys_name() and use it where ever logging_vty.c does removal of the leading 'D'. I would have liked to keep this within logging_vty.c, but unfortunately it needs to be public API in logging.h, because of log_parse_category() which also strips leading D and lives in logging.c. Change-Id: I5f81343e8c7b714a4630e64ba654e391435c4244
2024-04-09todo-releaseneels/report_lockNeels Hofmeyr1-0/+1
Change-Id: I6c63dddaa95f2fa59af86d4df6e172627515b470
2024-04-09add osmo_stats_report_lock apiNeels Hofmeyr4-0/+89
Allow multi-threaded access to reported stats: - enable use of a stats mutex with osmo_stats_report_use_lock(true). - lock/unlock externally with osmo_stats_report_lock(true/false). Rationale: In osmo-hnbgw, we would like to collect stats from nftables, and do so in a separate thead. The most efficient way is to write the parsing results from nft directly to the rate_ctr destination. But what if the main thread reports rate counters at exactly that time? - is writing to stats atomic on a data type level? - do applications need stats to be "atomic" as a whole? In osmo-hnbgw in particular, there are two counters, 'packets' and 'total_bytes'. These correspond, and it would skew statistics if we reported them out of sync to each other. The simplest way to ensure correctness in all cases is a mutex around the stats reporting. But this mutex isn't needed in most of our programs. To completely avoid any overhead the mutex may bring, make use of it optional with a global flag. This use case is likely to also show up in other programs that would like to collect and report stats from a separate thread. Related: SYS#6773 Related: osmo-hnbgw I9dc54e6bc94c553f45adfa71ae8ad70be4afbc8f Change-Id: Ib335bea7d2a440ca284e6c439066f96456bf2c2d
2024-03-28sockaddr_str: add conversion to,from osmo_sockaddrNeels Hofmeyr4-0/+28
Add functions to pass struct osmo_sockaddr to the osmo_sockaddr_str_{to,from}* API directly. So far the interface to osmo_sockaddr_str_ is: osmo_sockaddr_str_from_sockaddr(&my_sa_str, &my_osa->u.sas); I'm working a lot with osmo_sockaddr at the moment, and the cumulated time of forgetting to add 'u.sas' and having another compilation cycle because of those is justifying this additional API. Change-Id: I0df84b4bb8cb5d8434b735fa3a38e7f95be43e91
2024-03-23Add funding link to github mirrorHarald Welte1-0/+1
see https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/displaying-a-sponsor-button-in-your-repository Change-Id: I52d8c7cece35337eb33325146eccc8db005c55e3
2024-03-20Revert "Revert "logging: add log level cache""Hoernchen4-1/+146
This reverts commit 7f1fb3ea817578f3f2f63e8065aa50f8355caa3b - slightly amended with the new log_cache_enalbe() function. The cache is hence disabled by default, and applications can enable it, if they wish to benefit from it. Reason for the original revert was: some fallout expected due to log manipulation in test code Change-Id: I539872fc9e3c50b407e6bc388f1e091fa2c826c3
2024-03-20osmo_io_uring: Run check of tests/osmo_io with io_uring alsoAndreas Eversberg4-2/+16
Related: OS#5751 Change-Id: I82db9a15bc483a5447d86352512afaafa2bcfbb6
2024-03-19osmo_io: Make {write,sendto,sendmsg} completion callback optionalHarald Welte1-15/+6
There are situations (like multicast datagram transmit) where we don't really care about the result of a write operation, and hence don't need a write completion callback. As the completed message buffer is free'd by core osmo_io, there is no leak in doing so. Change-Id: I0c071a29e508884bac331ada5e510bbfcf440bbf
2024-03-19osmo_io: Massive improvement of API documentationHarald Welte2-53/+223
* introduce a new "Osmocom I/O interface" group to show up in API docs * expand the documentation to turn it into something useful for somebody wanting to write an application using it. Change-Id: I6315cfc7ff34a0f8971517edf035e1efcef3ed5c
2024-03-15osmo_io: Dont use __linux__ but !EMBEDDEDHarald Welte2-4/+4
osmo_io (unlike its io_uring backend) is not linux specific, so putting it in an "#ifdef __linux__" block is plain wrong. A side-effect is that all our doxygen comments are not processed as __linux__ is not set while doxygen parses the source file. Change-Id: I260443ba3cd0bb81dade434208dea4ea70fe8ad8
2024-03-14Fix file descriptor that is passed to io_uring_register_eventfd()Andreas Eversberg1-1/+1
Fix Change-Id I03752c0114cc6fad0c31fff6fff43072f36a50a7 Change-Id: Ie085c7cb3eb57e0da10485be8f90208cb41b0073
2024-03-14core: fix missing '\n' in iofd_uring_connected_cb()Vadim Yanitskiy1-1/+1
Change-Id: I43df86cdbd3e52d4f8f7bc0e48478b6f9b288e9f
2024-03-14io_uring: check all operations in osmo_iofd_uring_init()Harald Welte1-4/+17
check all operations in osmo_iofd_uring_init() and panic if any of them fails. Change-Id: I03752c0114cc6fad0c31fff6fff43072f36a50a7
2024-03-14io_uring: more verbose error messages if io_uring setup failsHarald Welte1-2/+2
"Assert failed 0 osmo_io_uring.c:94" is rather useless in terms of an error message. Let's improve upon that. Change-Id: I0ac9ae59e99c3704b3ce33919c9e7d11024476e3
2024-03-12socket: Add remote PID and local FD to AF_UNIX socknamePau Espin Pedrol1-3/+28
This allows identifying precisely an AF_UNIX socket. Change-Id: Ic465e557ea49de8e044d1ef6d91fc3c852c88ff2
2024-03-12socket: Support AF_UNIX in osmo_sock_get_name_buf()Pau Espin Pedrol1-7/+46
Right now stream_cli/srv print "<error-in-getsockname>" when using an AF_UNIX socket. This commit fixes the problem. Change-Id: I224c3712a029ee338ee1209a67d820b887170910
2024-03-12ctrl: re-introduce duplicate declaration of ctrl_cmd_send()Harald Welte1-0/+2
In Change-Id Ic81af56e7ea6921ba39168727ef64c308e9c6754 we removed the duplicate declaration of ctrl_cmd_send(), which was declared both in control_if.h and in control_cmd.h. Unfortunately this broke legacy openbsc.git, so let's re-introduce it. Change-Id: I1d415c5e80cfb7ef9e11d33c0c3eaece40ebb1da
2024-03-08osmo_io_poll: Use -errno as result on write errorAndreas Eversberg1-1/+1
This was done for read error in a previous patch. This is required because osmo_io_uring does not support errno, instead it uses the result code. To have a unified API, set the result code equally. Related: OS#5751 Change-Id: I405094449a6644db37534757f2fbccbcff982f23
2024-03-07osmo_io: Avoid implementing non-existant situationsHarald Welte1-7/+4
Both of our back-ends have a register_fd and unregister_fd back-end. Let's simplify the code by not treating them as optional, which introduces code paths that we never take, adds small runtime overhead and makes the code harder to follow. Should we ever introduce more backends which might not need those call-backs, we can either have empty functions or think about how to make them optional. Change-Id: I0077151eb676f61320b3fa2124448852aa8fd4a9
2024-03-07osmo_io: avoid OSMO_ASSERT one each API callHarald Welte1-2/+7
There's only one way to set the osmo_iofd_ops, which is by environment variable during the constructor time at shared library load time. There's hence no point in doing OSMO_ASSERT() on each and every call to osmo_iofd_notify_connected() at runtime. We can move those kind of asserts to the one-time load-time constructor instead. At the same time, we can extend those asserts to all the mandatory call-backs to be provided by the backend. Change-Id: Id9005ac6bb260236c88670373816bf7ee6a627f1
2024-03-07osmo_io: Don't pretend to support backends without close_cbHarald Welte1-2/+2
Let's not pretend we support backends without a close_cb. In such situations nobody would actually close(2) the file descriptor, but we would set iofd->fd to -1, effectively creating a file descriptor leak. Both of our two back-ends provide a close_cb, and we don't need to consider hypothetical future back-ends that would not like to register such a call-back. Related: OS#6393 Change-Id: Id285f1d7b73ae5805aa618897016ae8b73bf892d
2024-03-07osmo_io: Log error message in case call-backs incompatible with modeHarald Welte3-2/+20
Change-Id: I50ba6a76c0144f249d67488874a6c4edf01ec6f2
2024-03-07osmo_io: Guard osmo_iofd_register() with invalid file descriptorHarald Welte1-0/+5
Let's return an error if both osmo_iofd_setup() and osmo_iofd_register() are called with an invalid file descriptor like -1. Either one of them must have been called with a valid file descriptor. Change-Id: Ie4561cefad82e1bf5d37dd1a4815f4bc805343e6
2024-03-04osmo_io: do check_mode_callback_compat() only if ioops is set at ↵Andreas Eversberg1-1/+1
osmo_iofd_setup() Setting ioops is optional when calling osmo_iofd_setup(). If it is not set, do not call check_mode_callback_compat() to check for compatibility. Closes: Coverity CID#349578 Change-Id: I1e25f3e420f25a44cbf73a4da9a498b7561e9ddd
2024-03-02cbsp: Add osmo_cbsp_segmentation_cb for message segmentationlaforge/cbspHarald Welte3-0/+22
This call-back can for example be used as segmentation call-back for libosmo-netif stream_cli/stream_srv or directly for osmo_io. Related: OS#5755 Change-Id: I5e922c54b3431d759b38e81e55076125c5a34008
2024-03-02ctrl: Don't expose write_queue in ctrl_cmd_send() apiHarald Welte5-7/+19
ctrl_cmd_send() should always have taken a 'struct ctrl_connection' as argument, not directly its write_queue member. Let's offer a ctrl_cmd_send2() which fixes the problem, and deprecate the old ctrl_cmd_send(). Related: OS#5751 Change-Id: Ic81af56e7ea6921ba39168727ef64c308e9c6754
2024-03-02osmo_io_uring: Check if osmo_fd_register fails at iofd_uring_notify_connected()Andreas Eversberg1-2/+4
If it fails, do not set the IOFD_FLAG_NOTIFY_CONNECTED flag and log an error message. Closes: Coverity CID#349579 Change-Id: I34e8cc9a2b9df0c624841e5f9268a15c32418da1
2024-02-29osmo_io: Assign const name when stealing TX msg from iofd ctxAndreas Eversberg1-3/+1
All TX messages are moved from iofd instance to the user's context. iofd may be destroyed, but the message is still available to the user. To prevent a use-after-free bug, the context name must be changed from iofd->name to a constant that does not belong to iofd. Change-Id: Ib8dae924fa2d94a7f636136ba7279b965a18cf5b
2024-02-29osmo_io: Add osmo_io_get_ioops() functionHarald Welte3-0/+10
This function can be used by user code to obtain the currently-set io operations, it's the inverse of osmo_io_set_ioops(). Change-Id: I03398c811b9534f50c6644b21eea89a04be29fb0
2024-02-29osmo_io_poll: Declare local functions "static"Andreas Eversberg1-8/+8
Change-Id: I6ba88cd7bbd5b5ef42eb460679696f105c9158cb
2024-02-29osmo_io_uring: Detach msghdr from iofd before calling ↵Andreas Eversberg1-1/+9
iofd_handle_send_completion() msghdr must be detached, because subsequent callback at iofd_handle_send_completion() may destroy the iofd (which in turn frees this msghdr, if still attached) and frees the msghdr, causing a double free. Related: OS#5751 Change-Id: Ia349f73de2145fa360b20dd40deb73a8ffc71f07
2024-02-28osmo_io_uring: Cancel pending request, free msghdr on completionAndreas Eversberg1-4/+19
There is always a completion after cancelling a uring request. Because uring requests use msghdr pointer as user data, we cannot just free the msghdr after cancelling. Upon completion (received after cancelling), the user data still points to the msghdr. To prevent a use-after-free bug, msghdr is not freed, but detached from iofd instance. Then upon completion, the msghdr (if it was detached from iofd) is freed. Additionally it is not required to keep IOFD_FLAG_IN_CALLBACK set anymore, if there is a msghdr attached to iofd. As described above, all msghdr get detached, if iofd is freed (uring request get cancelled) during callback. Related: OS#5751 Change-Id: Ic253f085dd6362db85f029f46350951472210a02
2024-02-28osmo_io_poll: Use -errno as result on read errorAndreas Eversberg2-1/+2
Related: OS#5751 Change-Id: Ida63b74feecddf96bab7b2ade4e9ad216fe56e06
2024-02-28osmo_io: Reject writing messages with length of 0Andreas Eversberg1-0/+15
io_uring will reject to transmit messages with length of 0. Change-Id: I94be5ec7344d92157f7853c6c0ddf7007513ba8e Related: OS#5751
2024-02-28osmo_io: Use poll/select to notify socket connection at osmo_io_uring.cAndreas Eversberg2-1/+76
In order to receive a connect notification from SCTP socket, poll/select event must be used instead of a write notification via io_uring completion event. Once the connect notification has been received, subsequent write notifications via io_uring are used. Change-Id: I4eca9ea72beb0d6ea4d44cce81ed620033f07270 Related: OS#5751
2024-02-28osmo_io: sendmsg/recvmsg supportHarald Welte6-20/+169
Add support osmo_io operations resembling sendmsg() and recvmsg() socket operations. This is what will enable the implementation of higher-layer functions like equivalents of sctp_recvmsg() and sctp_send() in libosmo-netif and/or other users. Change-Id: I89eb519b22d21011d61a7855b2364bc3c295df82 Related: OS#5751
2024-02-28osmo_io: Move notify_connected function to backendAndreas Eversberg4-2/+29
This relocation is necessary as the backend (osmo_io_fd or osmo_io_uring) requires a different approach in handling connect notifications. As a result, a function call has been introduced to struct iofd_backend_ops. In a subsequent patch, the process for the osmo_io_uring backend will be modified to handle SCTP connect notifications using poll/select. If connect notification is requested using poll/select, the file descriptior must be registered to osmo_fd, using osmo_fd_register. If read / write notification is requested by application, the file descriptior must be registered also. A flag is used prevent calling osmo_fd_register / osmo_fd_unregister multiple times, which would cause a crash. Change-Id: I905ec85210570aff8addadfc9603335d04eb057a Related: OS#5751
2024-02-27gsup.h: define newly added PCO IEAlexander Couzens3-0/+19
PCO - Protocol Configuration Options 3GPP TS 24.008 / 10.5.6.3. The PCO will be used by the osmo-epdg to pass PCO internally. The PCO will be passed towards to the PGW in the Session Request. Related: OS#6369 Related: osmo-gsm-manuals.git Change-Id Id912ead4e1205f84a40af6505a5ddf050d1e086d Change-Id: I0f9de90c7c67fe194b441a9d118eba70f09afb5e
2024-02-23osmo_io: Change struct osmo_io_ops to contain struct, not unionHarald Welte4-37/+75
As we introduce more modes, and each mode aliases call-back function pointers to those of another mode, we have more and more error cases where we (for exampele) access read_cb, but in reality the user has populated recvfrom_cb. Let's use a struct, meaning that call-backs of one mode no longer alias to the same memory locations of call-backs fro another mode. This allows us to properly check if the user actually provided the right callbacks for the given mode of the iofd. This breaks ABI, but luckily not API. So a simple recompile of higher-layer library + application code will work. Change-Id: I9d302df8d00369e7b30437a52deb205f75882be3
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-24 23:38:33 +0000