From: Tobias Brunner <tobias@strongswan.org>
Date: Wed, 4 May 2016 13:39:51 +0000 (+0200)
Subject: kernel-netlink: Check proper watcher state in parallel mode
X-Git-Tag: 5.4.1dr2~2
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=fee991c2597abbb6de75fb4a256f4fd8fe5b5f1b;p=thirdparty%2Fstrongswan.git

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.
---

diff --git a/src/libcharon/plugins/kernel_netlink/kernel_netlink_shared.c b/src/libcharon/plugins/kernel_netlink/kernel_netlink_shared.c
index f7ce992a36..0e49987f67 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)
 			{