tree e28e3e7e789a1bedd2d604a8c58ad420a8ff420f
parent 3de8e7ab8d9125402cc1a8fb48ee475ee21d7d4c
author Willy Tarreau <w@1wt.eu> 1448479047 +0100
committer Willy Tarreau <w@1wt.eu> 1448531013 +0100
encoding latin1

BUG/MEDIUM: stream: fix half-closed timeout handling

client-fin and server-fin are bogus. They are applied on the write
side after a SHUTR was seen. The immediate effect is that sometimes
if a SHUTR was seen after a SHUTW on the same side, the timeout is
enabled again regardless of the fact that the output is already
closed. This results in the timeout event not to be processed and
a busy poll loop to happen until another timeout on the stream gets
rid of it. Note that haproxy continues its job during this, it's just
that it eats all the CPU trying to handle an event that it ignores.

An reproducible case consists in having a client stop reading data from
a server to ensure data remain in the response buffer, then the client
sends a shutdown(write). If abortonclose is enabled on haproxy, the
shutdown is passed to the server side and the server responds with a
SHUTR that cannot immediately be forwarded to the client since the
buffer is full. During this time the event is ignored and the task is
woken again in loops.

It is worth noting that the timeout handling since 1.5 is a bit fragile
and that it might be possible that other similar conditions still exist,
so the timeout handling should be audited regarding this issue.

Many thanks to BaiYang for providing detailed information showing the
problem in action.

This bug also affects 1.5 thus the fix must be backported.
(cherry picked from commit f25b3573d65fd2411c7537b7b0a4817b478df909)
[Note for 1.5, it's in session.c here]
(cherry picked from commit 44e86286159474a52dc74f80d3271504cc6f1550)