In some situations it was observed that recvmsg() blocks even if epoll_wait() reports the netlink socket as ready:
select(15, [3 9 10 14], [], [], NULL) = 1 (in [9]) epoll_wait(9, [{EPOLLIN, {u32=8, u64=8}}], 2, -1) = 1 recvmsg(8, ### blocked
(9 is the epoll fd, 8 the nl_cli event socket).
Probably this is caused by a bug in kernel, however it seems more robust anyway to set the socket as non-blocking to avoid problems like this.
Signed-off-by: Beniamino Galvani bgalvani@redhat.com --- libteam/libteam.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/libteam/libteam.c b/libteam/libteam.c index 0065a7f..9c9c93a 100644 --- a/libteam/libteam.c +++ b/libteam/libteam.c @@ -638,6 +638,7 @@ int team_init(struct team_handle *th, uint32_t ifindex) nl_socket_modify_cb(th->nl_cli.sock_event, NL_CB_VALID, NL_CB_CUSTOM, cli_event_handler, th); nl_cli_connect(th->nl_cli.sock_event, NETLINK_ROUTE); + nl_socket_set_nonblocking(th->nl_cli.sock_event);
env = getenv("TEAM_EVENT_BUFSIZE"); if (env) {
Tue, May 28, 2019 at 10:02:45AM CEST, bgalvani@redhat.com wrote:
In some situations it was observed that recvmsg() blocks even if epoll_wait() reports the netlink socket as ready:
select(15, [3 9 10 14], [], [], NULL) = 1 (in [9]) epoll_wait(9, [{EPOLLIN, {u32=8, u64=8}}], 2, -1) = 1 recvmsg(8, ### blocked
(9 is the epoll fd, 8 the nl_cli event socket).
Probably this is caused by a bug in kernel, however it seems more robust anyway to set the socket as non-blocking to avoid problems like this.
Signed-off-by: Beniamino Galvani bgalvani@redhat.com
applied, thanks.
libteam@lists.fedorahosted.org