As found in PR #75525, we should not modify the polled fd array
in multiple places. Because of this fix, the async version of
the socket service could start to trigger while it is being handled
by the async handler. This basically means that the async version
cannot work as intended so remove its support.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
pollfd array used with zsock_poll() should not be modified while inside
zsock_poll() function as this could lead to unexpected results. For
instance, k_poll already monitoring some kernel primitive could report
an event, but it will not be processed if the monitored socket file
descriptor in the pollfd array was set to -1. In result,
zsock_poll() may unexpectedly quit prematurely, returning 0 events, even
if it was requested to wait infinitely.
The pollfd arrays used by zsock_poll() (ctx.events) is reinitialized
when the service thread is restarted so modifying it directly when
registering/unregistering service is not really needed. It's enough if
those functions notify the eventfd socket used to restart the services
thread.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In case of thread failure, fix the registrations by properly managing
the synchronization i.e. use conditional wait only if thread is being
initialized or will be initialized, else check for success or failure
without waiting for conditional variables.
Fixes#73523.
Signed-off-by: Chaitanya Tata <Chaitanya.Tata@nordicsemi.no>
Until recently, the posix api was purely a consumer of the
network subsystem. However, a dependency cycle was added as
a stop-gap solution for challenges with the native platform.
Specifically,
1. eventfd symbols conflict with those of the host
2. eventfd was excluded from native libc builds via cmake
If any part of the posix were then to select the network
subsystem (which is a legitimate use case, given that networking
is a part of the posix api), we would get a build error due to
the Kconfig dependency cycle.
As usual, with dependency cycles, the cycle can be broken
via a third, mutual dependency.
What is the third mutual dependency? Naturally, it is ZVFS
which was planned some time ago. ZVFS will be where we
collect file-descriptor and FILE-pointer APIs so that we can
ensure consistency for Zephyr users.
This change deprecates EVENTFD_MAX in favour of
ZVFS_EVENTFD_MAX.
Signed-off-by: Chris Friedt <cfriedt@tenstorrent.com>
Do not depend on init level but start the socket service
already in net core init because DNS init code depends on
socket service API to be ready to serve. And we call DNS
init at the net core init.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Add checks to make sure that we are not trying to use the socket
service library with eventfd if CONFIG_POSIX_API is not set and if
using native_sim based board. The reason is that we should always
use zephyr libc based eventfd implementation instead of host libc one.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
This reverts commit b56297bf16
because it is causing problems when using native_sim and not
having CONFIG_POSIX_API set.
The proper fix is to set CONFIG_POSIX_API when using eventfd
and native_sim so that picolibc is used instead of host libc.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
With native_sim, this error is seen a lot when socket
service API is used.
<dbg> net_sock: get_sock_vtable: (net_socket_service):
Invalid access on sock 3 by thread 0x807a8e0 (net_socket_service)
If we just ignore the error, then we might get into forever
loop which is not good. So if this happens, mark the eventfd
fd as not pollable to basically ignore the eventfd support in
this case.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Instead of using net_context API directly, the DNS resolver is
changed to use the socket service API. This allows DNS access
for offloaded sockets and can lower overall memory consumption.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
Socket service pollfd count should not exceed the configured
NET_SOCKETS_POLL_MAX limit, as poll() will not be able to monitor
sockets beyond that limit anyway. Adding +1 there prevented the library
from catching the configuration error.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
If the CONFIG_NET_SOCKETS_POLL_MAX is smaller than what is needed
for the socket service API to work properly, then we should not
start the service thread as the service API cannot work and might
cause memory overwrite in ctx.events[] array.
Fixes#69233
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
We cannot always start the service monitor thread statically
because the static threads are started after the application
level. This means that when config library wants to start
dhcpv4 server which uses socket services, there would be a
deadlock. Simplest solution is to start the service thread
directly from socket service init function.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
User is able to tweak the socket service dispatcher thread
priority in order to get better performance from the system
if needed. By default the dispatcher thread runs in lowest
application thread priority (K_LOWEST_APPLICATION_THREAD_PRIO).
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
The socket service provides a similar functionality as what
initd provides in Linux. It listens user registered sockets
for any activity and then launches a k_work for it. This way
each application does not need to create a thread to listen
a blocking socket.
Signed-off-by: Jukka Rissanen <jukka.rissanen@nordicsemi.no>
