]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: listener/threads: fix a remaining race in the listener's accept()
authorWilly Tarreau <w@1wt.eu>
Tue, 10 Dec 2019 08:30:05 +0000 (09:30 +0100)
committerWilly Tarreau <w@1wt.eu>
Tue, 10 Dec 2019 09:43:31 +0000 (10:43 +0100)
commit92079934a913a330a57e6d84eba3dca68c0cde8e
treeaa2ffed3d3f18dbf231cb091582880769b185dd6
parent20aeb1c7cd38907d704a4d769695b9ea264fa4c0
BUG/MEDIUM: listener/threads: fix a remaining race in the listener's accept()

Recent fix 4c044e274c ("BUG/MEDIUM: listener/thread: fix a race when
pausing a listener") is insufficient and moves the race slightly farther.
What now happens is that if we're limiting a listener due to a transient
error such as an accept() error for example, or because the proxy's
maxconn was reached, another thread might in the mean time have switched
again to LI_READY and at the end of the function we'll disable polling on
this FD, resulting in a listener that never accepts anything anymore. It
can more easily happen when sending SIGTTOU/SIGTTIN to temporarily pause
the listeners to let another process bind next to them.

What this patch does instead is to move all enable/disable operations at
the end of the function and condition them to the state. The listener's
state is checked under the lock and the FD's polling state adjusted
accordingly so that the listener's state and the FD always remain 100%
synchronized. It was verified with 16 threads that the cost of taking
that lock is not measurable so that's fine.

This should be backported to the same branches the patch above is
backported to.
src/listener.c