Re: "[ANNOUNCE] haproxy-2.3.6

2021-03-05 Thread Willy Tarreau
Hi William,

On Fri, Mar 05, 2021 at 01:28:34PM +0100, William Dauchy wrote:
> Hi,
> 
> On Wed, Mar 3, 2021 at 4:09 PM Christopher Faulet  wrote:
> >- An issue leading to possible infinite loops because of a double locking
> >  effect in the mt lists was fixed by Olivier. If MT_LIST_TRY_ADDQ()
> >  macro, it was possible to try to lock twice the same element, making 
> > the
> >  second lock attempt to fail in loop.
> > Olivier Houchard (1):
> >BUG/MEDIUM: lists: Avoid an infinite loop in MT_LIST_TRY_ADDQ().
> 
> not very clear in which conditions it can be triggered. Do you have
> more details about it?

That's something I encountered while trying to simplify some code, I
noticed that under certain circumstances my tests would deadlock, even
with a single thread. I seem to remember that it happens with there's
exactly one element in the list and you try to add it again into the
same list. It just turns out that the rare places where this is used
could not trigger this condition. And its sibling, MT_LIST_TRY_ADD()
was safe.

Hoping this helps,
Willy



Re: "[ANNOUNCE] haproxy-2.3.6

2021-03-05 Thread William Dauchy
Hi,

On Wed, Mar 3, 2021 at 4:09 PM Christopher Faulet  wrote:
>- An issue leading to possible infinite loops because of a double locking
>  effect in the mt lists was fixed by Olivier. If MT_LIST_TRY_ADDQ()
>  macro, it was possible to try to lock twice the same element, making the
>  second lock attempt to fail in loop.
> Olivier Houchard (1):
>BUG/MEDIUM: lists: Avoid an infinite loop in MT_LIST_TRY_ADDQ().

not very clear in which conditions it can be triggered. Do you have
more details about it?

Thanks,

-- 
William



"[ANNOUNCE] haproxy-2.3.6

2021-03-03 Thread Christopher Faulet



Hi,

HAProxy 2.3.6 was released on 2021/03/03. It added 55 new commits after
version 2.3.5.

Several fixes for this release, most of them are minor, but some ones may
have visible effects :

  - An issue leading to possible infinite loops because of a double locking
effect in the mt lists was fixed by Olivier. If MT_LIST_TRY_ADDQ()
macro, it was possible to try to lock twice the same element, making the
second lock attempt to fail in loop.

  - Dragan addressed a long-standing issue in the way variables are used as
arguments to converters. First they were never locked, resulting in bad
things when accessing shared variables in the "proc" scope. And the
argument was improperly checked: if it didn't parse it was implicitly a
variable, but that could die in some circumstances (such as truncated
base64 values to "base64"). Dragan had no other option but to add
boot-time config checks that may trigger errors on currently invalid
configs that silently validate. If it proves to be problematic, we could
try to replace the error with a warning and use whatever we find
reliable enough.

  - Willy fixed a thread-safety issue when a stream was killed on a
hard-stop or when using "shutdown sessions" over the CLI. The streams
list was not locked. This issue might lead to a crash if an already dead
stream was shut down. Now, these operations are using thread_isolate()
to guarantee no other threads are running in same time.

  - Willy also optimized the health_adjust() function by reducing the server
lock scope, grabbing it only when required. This function is used to
adjust the server status depending on the communication with the server,
via the "observe" parameter. He also fixed a time wrapping issue in this
function, a bug introduced with the feature, more than 10 years ago,
preventing some health-checks to be immediately triggered half of the
time.

  - Two bugs were fixed on the H1 multiplexer. The first one is a
regression. The client side might be blocked at the end of a transaction
if a "Connection: upgrade" was found in a response other than
101-Switching-Protocol, preventing the following request to be
parsed. This happened because of a missing flag on the H1 connection on
the server side, keeping it attached to the stream. The second one was
an issue with the responses to CONNECT requests other than 200-Ok. If
the requested tunnel establishment was not performed by a server, the
end of the transaction was not properly detected, closing the connection
on the client side.

  - Willy fixed another very old bug (13 years !) about queue and tarpit
timeouts picked from the last defaults section during the configuration
check validity. Looking at the wrong defaults section. It should be the
one before the evaluated proxy. The worst part of it is that it might
have randomly worked by accident for some configurations when there was
a single defaults section, but has certainly caused too short queue
expirations once another defaults section was added later in the file
with these explicitly defined.

  - A segmentation fault in the SPOE filter was fixed when a logger to a
ring buffer was used. The corresponding sink was not resolved during the
post parsing staged. In addition, in multi-threaded mode, the SPOE
applets are now killed if there are pending connections. This is
important to not let queued sessions waiting forever. SPOE connections
are persistent and sticky to a thread. Thus with a low maxconn value,
for instance 1, some threads might hold all available slots, leaving
other threads with no free slots.

  - Two issues were fixed on the DNS resolvers. The first one was about the
loading of obsoletes server ip/port when a server-state file was
used. These information were not reset when an server resolution failed
or when obsoletes SRV records were removed. Another issue was about the
unconditional TTL renew of SRV records when found in a DNS response.
SRV records with no additional record were never expired.

  - The server-state-file-name directive was fixed. Since the beginning, in
contrary to what the documentation said, this directive was not able to
be used with no parameter. To use the backend name as file name, the
undocumented parameter "use-backend-name" had to be used instead. Now,
both modes are supported. Another issue about the server-state file was
fixed. If the name of local server-state file was too long, the fopen()
function was called with a NULL file name. Finally, the RMAINT admin
mode is now ignored when a server state is loaded. Before, when this
admin mode was set, an error was reported, preventing the server state
to be loaded.

  - The tracked sessions counter was not atomically incremented, resulting
in occasional slightly off values.

  - The