]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MINOR: queue/threads: make the queue unlinking atomic
authorWilly Tarreau <w@1wt.eu>
Thu, 14 Nov 2019 13:58:39 +0000 (14:58 +0100)
committerWilly Tarreau <w@1wt.eu>
Thu, 14 Nov 2019 13:58:39 +0000 (14:58 +0100)
commit9ada030697c945d0e4bcbc85870d6d25f33b76b0
treee64b9f672e22cfbcf2d5836c32d5cfa73a888b7f
parent7031e3daced2169a2ebc5041611a2f05310f130f
BUG/MINOR: queue/threads: make the queue unlinking atomic

There is a very short race in the queues which happens in the following
situation:
  - stream A on thread 1 is being processed by a server
  - stream B on thread 2 waits in the backend queue for a server
  - stream B on thread 2 is fed up with waiting and expires, calls
    stream_free() which calls pendconn_free(), which sees the
    stream attached
  - at the exact same instant, stream A finishes on thread 1, sees
    one stream is waiting (B), detaches it and wakes it up
  - stream B continues pendconn_free() and calls pendconn_unlink()
  - pendconn_unlink() now detaches the node again and performs a
    second deletion (harmless since idempotent), and decrements
    srv/px->nbpend again

=> the number of connections on the proxy or server may reach -1 if/when
   this race occurs.

It is extremely tight as it can only occur during the test on p->leaf_p
though it has been witnessed at least once. The solution consists in
testing leaf_p again once the lock is held to make sure the element was
not removed in the mean time.

This should be backported to 2.0 and 1.9, probably even 1.8.
src/queue.c