From: Olivier Houchard <ohouchard@haproxy.com>
Date: Thu, 8 Feb 2018 16:03:33 +0000 (+0000)
Subject: BUG/MINOR: fd/threads: properly lock the FD before adding it to the fd cache.
X-Git-Tag: v1.9-dev1~427
X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=1ff9104117c67c99130c3b141d8fc236b3aa22a7;p=thirdparty%2Fhaproxy.git

BUG/MINOR: fd/threads: properly lock the FD before adding it to the fd cache.

It was believed that it was useless to lock the "prev" field when adding a
FD. However, if there's only one element in the FD cache, and that element
removes itself from the fd cache, and another FD is added before the first
add completed, there's a risk of losing elements. To prevent that, lock the
"prev" field, so that such a removal will wait until the add completed.
---

diff --git a/src/fd.c b/src/fd.c
index d6c140c0ce..1af64e543d 100644
--- a/src/fd.c
+++ b/src/fd.c
@@ -198,7 +198,7 @@ redo_last:
 	last = list->last;
 	old = -1;
 
-	fdtab[fd].cache.prev = last;
+	fdtab[fd].cache.prev = -2;
 	/* Make sure the "prev" store is visible before we update the last entry */
 	__ha_barrier_store();
 
@@ -224,6 +224,7 @@ redo_last:
 	/* since we're alone at the end of the list and still locked(-2),
 	 * we know noone tried to add past us. Mark the end of list.
 	 */
+	fdtab[fd].cache.prev = last;
 	fdtab[fd].cache.next = -1;
 	__ha_barrier_store();
 done: