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 d6c140c0ce057778b1d36ab0de00a836d4b921bb..1af64e543d5fe81d56712b3cc6c2a53834c86e40 100644 (file)
--- 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: