From fee991c2597abbb6de75fb4a256f4fd8fe5b5f1b Mon Sep 17 00:00:00 2001 From: Tobias Brunner Date: Wed, 4 May 2016 15:39:51 +0200 Subject: kernel-netlink: Check proper watcher state in parallel mode After adding the read callback the state is WATCHER_QUEUED and it is switched to WATCHER_RUNNING only later by an asynchronous job. This means that a thread that sent a Netlink message shortly after registration might see the state as WATCHER_QUEUED. If it then tries to read the response and the watcher thread is quicker to actually read the message from the socket, it could block on recv() while still holding the lock. And the asynchronous job that actually read the message and tries to queue it will block while trying to acquire the lock, so we'd end up in a deadlock. This is probably mostly a problem in the unit tests. --- src/libcharon/plugins/kernel_netlink/kernel_netlink_shared.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'src/libcharon/plugins/kernel_netlink/kernel_netlink_shared.c') diff --git a/src/libcharon/plugins/kernel_netlink/kernel_netlink_shared.c b/src/libcharon/plugins/kernel_netlink/kernel_netlink_shared.c index f7ce992a3..0e49987f6 100644 --- a/src/libcharon/plugins/kernel_netlink/kernel_netlink_shared.c +++ b/src/libcharon/plugins/kernel_netlink/kernel_netlink_shared.c @@ -309,7 +309,7 @@ static status_t send_once(private_netlink_socket_t *this, struct nlmsghdr *in, while (!entry->complete) { if (this->parallel && - lib->watcher->get_state(lib->watcher) == WATCHER_RUNNING) + lib->watcher->get_state(lib->watcher) != WATCHER_STOPPED) { if (this->timeout) { -- cgit v1.2.3