BUG/MEDIUM: lb-leastconn: Reposition a server using the right eweight
authorChristopher Faulet <cfaulet@haproxy.com>
Fri, 11 Dec 2020 14:36:01 +0000 (15:36 +0100)
committerChristopher Faulet <cfaulet@haproxy.com>
Mon, 14 Dec 2020 09:26:44 +0000 (10:26 +0100)
commit0881842bf7a8de3e3cf93bece19f160945ba984a
tree4ac8e64b9f881984668055092e9433502599a80e
parent7f955e66b93625ad405405f10bd51b94ffff72fe
BUG/MEDIUM: lb-leastconn: Reposition a server using the right eweight

Depending on the context, the current eweight or the next one must be used
to reposition a server in the tree. When the server state is updated, for
instance its weight, the next eweight must be used because it is not yet
committed. However, when the server is used, on normal conditions, the
current eweight must be used.

In fact, it is only a bug on the 1.8. On newer versions, the changes on a
server are performed synchronously. But it is safer to rely on the right
eweight value to avoid any futur bugs.

On the 1.8, it is important to do so, because the server state is updated
and committed inside the rendez-vous point. Thus, the next server state may
be unsync with the current state for a short time, waiting all threads join
the rendez-vous point. It is especially a problem if the next eweight is set
to 0. Because otherwise, it must not be used to reposition the server in the
tree, leading to a divide by 0.

This patch must be backported as far as 1.8.

(cherry picked from commit cb33d3ac7f8dbc3f7323606a521d29dc100adbda)
Signed-off-by: Christopher Faulet <cfaulet@haproxy.com>
src/lb_fwlc.c