]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: stconn: Only consider I/O timers to update stream's expiration date
authorChristopher Faulet <cfaulet@haproxy.com>
Mon, 16 Dec 2024 10:04:53 +0000 (11:04 +0100)
committerChristopher Faulet <cfaulet@haproxy.com>
Mon, 16 Dec 2024 16:47:25 +0000 (17:47 +0100)
commit4f32d03360e42a3e7fe4ed71012ec90339b9731d
tree7856205fd8c2a1d3855726a97d6d7b7589e5cb79
parente3b760ebcc45b58e121a282a3403971619e4e6c2
BUG/MEDIUM: stconn: Only consider I/O timers to update stream's expiration date

In sc_notify(), it remained a case where it was possible to set an
expiration date on the stream in the past, leading to a crash because of a
BUG_ON(). This must never happen of course.

In sc_notify(), The stream's expiration may be updated in case no wakeup
conditions are encoutered. In that case, we must take care to never set an
expiration date in the past. However, it appeared there was still a
condition to do so. This code is based on an implicit postulate: the
stream's expiration date must always be set when we leave
process_stream(). It was true since the 2.9. But in 3.0, the buffer
allocation mechanism was improved and on an alloc failure in
process_stream(), the stream is inserted in a wait-list and its expiration
date is set to TICK_ETERNITY. With the good timing, and an analysis
expiration date set on a channel, it is possible to set the stream's
expiration date in past.

After analysis, it appeared that the proper way to fix the issue is to only
evaluate I/O timers (read and write timeout) and not stream's timers
(analase_exp or conn_exp) because only I/O timers may have changed since the
last process_stream() call.

This patch must be backported as far as 3.0 to fix the issue. But it is
probably a good idea to also backported it as far as 2.8.
src/stconn.c