[OpenWrt-Devel] Mismatch in ubus / uloop options
nbd at openwrt.org
Mon Dec 7 12:06:41 EST 2015
On 2015-12-07 10:41, Karl Vogel wrote:
> In ubus_reconnect, the ctx->sock.fd is created and set to non-blocking mode:
> fcntl(ctx->sock.fd, F_SETFL, fcntl(ctx->sock.fd, F_GETFL) |
> O_NONBLOCK | O_CLOEXEC);
> However, further in the call stack, the socket will get added to uloop
> via ubus_add_uloop with the flag ULOOP_BLOCKING set.
> ie when called from ubus_complete_request on an !registered ctx->sock,
> the ubus_add_uloop is done:
> The uloop function assumes a socket is blocking by default and will
> never make a socket blocking again, it will only turn it to non-blocking
> if ULOOP_BLOCKING isn't set. This caused a busy loop in some daemons
> that had their socket set to non-blocking due to another issue, ie. poll
> using 0 as infinite instead of -1, for which I submitted a fix earlier.
> I wonder if it wouldn't be better to have uloop set the socket flags in
> all cases? Currently it "assumes" the socket is blocking and if
> ULOOP_BLOCKING is passed, it will set it to non-blocking, but it won't
> do the other way round. Though that might have some impact on daemons
> that think the socket is non-blocking while it will be turned into
> blocking if this is changed. So not sure what the best way to go about
> this one is?!
I think this uloop adding/removing of sockets in ubus is just a leftover
that should be removed. Needs some testing though.
These calls were added in combination with code that ran uloop_run()
inside blocking requests. I got rid of that due to recursion issues and
switched to using poll() directly, but apparently forgot to clean up the
adding/removing of sockets.
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel