When uloop_process_add() is called outside of uloop_run(), i.e. not
from a callback (which is the case of at least utrace and ujail),
child events can be missed. The reason is that when SIGCHILD handler
is installed in uloop_run(), after the uloop_process_add() is called,
then an initial signal could be missed.
Commit 4e3a47a ("uloop: use a waker for notifying sigchld and loop
cancel events", 2016-06-09) solved a similar problem and introduced
uloop_init() but forgot to move a call to uloop_setup_signals() there.
This is what this commit does.
Now, uloop_process_add() can be called any time after uloop_init()
without missing any event.
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
Acked-by: Yousong Zhou <yszhou4tech@gmail.com>
Variable confusion was breaking timers
Fixes: 368fd26458 ("uloop: allow specifying a timeout for uloop_run()")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Calling t->complete in runqueue_task_complete can free the memory
associated with t. Change the runqueue_start_next accordingly.
Fixes https://github.com/openwrt/openwrt/issues/493
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This can be useful for cleanup with pending timers, or for hooking into
existing code that does not use uloop
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This wires in custom expression handler functionality, which was present
in json script since the original version, but never used.
Signed-off-by: Denis Osvald <denis.osvald@sartura.hr>
Signed-off-by: Felix Fietkau <nbd@nbd.name> [error handling fix]
This is intended to fix the following compiler warning in opkg-lede:
/home/yousong/git-repo/lede-project/opkg-lede/libopkg/file_util.c: In function ‘file_md5sum_alloc’:
/home/yousong/git-repo/lede-project/opkg-lede/libopkg/file_util.c:144:2: warning: passing argument 1 of ‘md5sum’ discards ‘const’ qualifier from pointer target type [enabled by default]
In file included from /home/yousong/git-repo/lede-project/opkg-lede/libopkg/file_util.c:28:0:
/home/yousong/.usr/include/libubox/md5.h:56:5: note: expected ‘char *’ but argument is of type ‘const char *’
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
This adds support for double floating point type to make it more JSON
compatible. For type checking it also adds a stub BLOB_ATTR_DOUBLE type.
If necessary, the accessor functions for blob can be added later
Signed-off-by: André Gaul <andre@gaul.io>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This creates a mapping with twice the size of the allocated memory. The
second half of that mapping points at the same memory as the first half.
This is useful for ring buffers, because any read starting in the first
half can overflow into the second half as long as the read size is
smaller than the size of the memory area.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
ev.data is a union, so setting ev.data.fd is lost after setting
ev.data.ptr
Reported-by: Song Yaofei <songyaofei@joyware.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
The current blobmsg_format_json* functions will return invalid JSON when
the "list" argument is given as false (blobmsg_format_element() will
output the name of the blob_attr as if the value is printed as part of a
JSON object).
To avoid breaking software relying on this behaviour, introduce new
functions which will never print the blob_attr name and thus always
produce valid JSON.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Acked-by: Jo-Philipp Wich <jo@mein.io>
Signed-off-by: Felix Fietkau <nbd@nbd.name> [cosmetic style fix]
Recent glibc warns if result of read() or write() is unused.
Added a retry in case of EINTR, all other faults are silently discarded.
Signed-off-by: Eyal Birger <eyal.birger@gmail.com>
-----
- I was not able to reproduce the EINTR case, but it seems to be the right
thing to do
- Retrying on EAGAIN in this case would be weird as there is no one to read
from the other end of the pipe. We could call waker_consume() directly but
since the size of the message is just one byte, I think this would be dead
code
When a process quits in response to a signal it handles, it should to so
be re-sending the signal to itself. This especially important for SIGINT,
as is explained in [1].
uloop currently hides the reason for quitting uloop_run(). Fix this by
returning the signal that caused the loop to quit (or 0 when uloop_end()
was used), so a program using loop an comply with [1].
[1] https://www.cons.org/cracauer/sigint.html
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Consistently handle allocation failures. Some functions are changed to
return bool or int instead of void to allow returning an error.
Also fix a buffer size miscalculation in lua/uloop and use _exit() instead
of exit() on errors after forking.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Fix a race condition when do_sigchld, uloop_cancelled were set just
before epoll_wait(timeout=-1), resulting the loop stuck in the syscall
without noticing the events just happened
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
We already serialize BLOBMSG_TYPE_UNSPEC as "null" so represent JSON null
values as blob attribute type unspec with payload size zero.
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
Different distributions have different names for the lua 5.1 package.
Use cmake's built in pkg-config support to search for the first one,
rather than running it explicitly and searching for a single version.
Signed-off-by: Karl Palsson <karlp@remake.is>
Race is possible in ulog_kmsg(): if no /dev/kmsg exists
(e.g. while /dev gets re-mounted) regular file created instead.
>From this point system goes without kernel logger:
special character file can't be created anymore, all clients keep
overwriting single message in regular file.
To avoid this we open file in "r+" mode which doesn't create
file if it's not found.
Signed-off-by: Sergiy Kibrik <sakib@meta.ua>
Cc: John Crispin <blogic@openwrt.org>
The default uloop error handling is to delete the fd. Continue to do
that, but also set the write_error flag and notify the user.
Signed-off-by: Philip Craig <philipjcraig@gmail.com>
