tree a82e4b4683679796b6fbdf2703135fa91ae2d48f
parent c89b09b85a1a21df12dab9168635f794dc38b6c1
author Willy Tarreau <w@1wt.eu> 1460387042 +0200
committer Willy Tarreau <w@1wt.eu> 1460392512 +0200
encoding latin1

BUG/MAJOR: channel: fix miscalculation of available buffer space (2nd try)

Commit 999f643 ("BUG/MEDIUM: channel: fix miscalculation of available buffer
space.") introduced a bug which made output data to be ignored when computing
the remaining room in a buffer. The problem is that channel_may_recv()
properly considers them and may declare that the FD may be polled for read
events, but once the even strikes, channel_recv_limit() called before recv()
says the opposite. In 1.6 and later this case is automatically caught by
polling loop detection at the connection level and is harmless. But the
backport in 1.5 ends up with a busy polling loop as soon as it becomes
possible to have a buffer with this conflict. In order to reproduce it, it
is necessary to have less than [maxrewrite] bytes available in a buffer, no
forwarding enabled (end of transfer) and [buf->o >= maxrewrite - free space].

Since this heavily depends on socket buffers, it will randomly strike users.
On 1.5 with 8kB buffers it was possible to reproduce it with httpterm using
the following command line :

   $ (printf "GET /?s=675000 HTTP/1.0\r\n\r\n"; sleep 60) | \
       nc6 --rcvbuf-size 1 --send-only 127.0.0.1 8002

This bug is only medium in 1.6 and later but is major in the 1.5 backport,
so it must be backported there.

Thanks to Nenad Merdanovic and Janusz Dziemidowicz for reporting this issue
with enough elements to help understand it.
(cherry picked from commit 8a32106fffb4642687af76c78fd3c171847c917e)
(cherry picked from commit 9c09ee87836bb2efd78a17f9b16d8afe0ec64018)