ubus/lua: pass notification name to callback The callback function registered to be invoked when subscribing to a notification was only passed the notification data (if any) but not the name of the notification. This name is now passed as second argument to remain backwards compatible. The example subscriber.lua has also be updated. Signed-off-by: Dirk Feytons <dirk.feytons@gmail.com>
valgrind complained about these ==18834== Warning: invalid file descriptor -1 in syscall close() ==18834== at 0x5326D20: __close_nocancel (syscall-template.S:84) ==18834== by 0x5046DC7: ubus_process_obj_msg (libubus-obj.c:143) ==18834== by 0x5045E98: ubus_process_msg (libubus.c:106) ==18834== by 0x50468D0: ubus_handle_data (libubus-io.c:314) ==18834== by 0x4E3D125: uloop_run_events (uloop.c:198) ==18834== by 0x4E3D125: uloop_run_timeout (uloop.c:555) ==18834== by 0x109BEF: uloop_run (uloop.h:111) ==18834== by 0x109BEF: main (main.c:25) Signed-off-by: John Crispin <john@phrozen.org>
fix invalid close() call valgrind complained about this one ==18632== Warning: invalid file descriptor -1 in syscall close() ==18632== at 0x5326D20: __close_nocancel (syscall-template.S:84) ==18632== by 0x5046C02: ubus_process_invoke (libubus-obj.c:98) ==18632== by 0x5046DC3: ubus_process_obj_msg (libubus-obj.c:142) ==18632== by 0x5045E98: ubus_process_msg (libubus.c:106) ==18632== by 0x50468D0: ubus_handle_data (libubus-io.c:314) ==18632== by 0x4E3D125: uloop_run_events (uloop.c:198) ==18632== by 0x4E3D125: uloop_run_timeout (uloop.c:555) ==18632== by 0x109BEF: uloop_run (uloop.h:111) ==18632== by 0x109BEF: main (main.c:25) Signed-off-by: John Crispin <john@phrozen.org>
ubusd: move global retmsg per client Even with the tx_queue-ing issue resolved, what seems to happen afterwards, is that all the messages seems to get through, but the client still loops in the `ubus_complete_request()` waiting for `req->status_msg` or for a timeout. Though, the timeout does not seem to happen, because the data is processed in `ubus_poll_data()`, with a infinite poll() timeout (ubus_complete_request() is called with timeout 0). It's likely that either the `seq` or `peer` sent from ubusd are wrong, and the client cannot get the correct ubus request in `ubus_process_req_msg()`. I haven't digged too deep into this ; setting the `retmsg` object on the client struct seems to have resolved any hanging with the `ubus list` command. Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com> Signed-off-by: Felix Fietkau <nbd@nbd.name> [fix placement of retmsg in cl]
ubusd: don't free messages in ubus_send_msg() anymore This makes it clear that `ubus_msg_send()` is only about sending and queue-ing messages, and has nothing to do with free-ing. It can be a bit misleading/confusing when trying to go through the code and make assumptions about whether a buffer is free'd in ubus_send_msg(), or is free'd outside. In `ubusd_proto_receive_message()` the `ubus_msg_free()` is now called before the `if (ret == -1)` check. That way, all callbacks will have their messages free'd, which is what's desired, but confusing, because: * ubusd_handle_invoke() called ubus_msg_free() before returning -1 * ubusd_handle_notify() called ubus_msg_free() before returning -1 * ubusd_handle_response() called ubus_msg_send(,,free=true) before returning -1 * ubus_msg_send() would call ubus_msg_send(,,free=false) * all other callback callers would `ubus_msg_send(,,free=true)` (free the buffers in ubus_msg_send() ) In all other places, where `ubus_msg_send(,,free=true)` an explicit `ubus_msg_free()` was added. Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
libubus: Fix deletion from context's object AVL tree when removing object Objects are stored in the ubus context in an AVL tree. An AVL tree node contains a pointer to a key value. For the ubus context, this points to the id member of the object structure. In ubus_remove_object_cb, the id member is set to zero and then after, avl_delete is called and fails. To fix this, we call avl_delete before setting the object id to zero. Signed-off-by: Bob Ham <bob.ham@tomltd.co.uk>
ubusd: fix incomplete copy of shared buf during queue-ing For a shared ubus_msg_buf, the ubus_msg_ref function will create a copy for queue-ing. Problem is, that during the dequeue (especially) in client_cb, the header is 0-ed (because it's was a newly alloc-ed buffer). And during ubus_msg_writev(), the header info will be ignored by the client. Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
libubus: do not modify uloop_cancelled uloop_cancelled was used for two purposes within ubus_complete_request: - interrupting recursive requests on SIGINT/SIGTERM - breaking out of the poll loop in a recursive request that completed Saving/restorung uloop_cancelled was buggy, leading to SIGTERM not being processed properly. Simplify the logic by using a separate field for internal use Signed-off-by: Felix Fietkau <nbd@nbd.name>
ubusd: fix issue caused by an implicit cast An -1 returned by ubus_msg_writev() will be interpreted as UINT_MAX during a check to see how much data had could be written on the socket. Because sizeof() will return size_t it will promote the comparsion to unsigned Signed-off-by: Mihai Richard <mihairichard@live.com>