]> git.ipfire.org Git - thirdparty/haproxy.git/commit
MEDIUM: stream: remove the confusing SF_ADDR_SET flag
authorWilly Tarreau <w@1wt.eu>
Mon, 2 May 2022 14:36:47 +0000 (16:36 +0200)
committerWilly Tarreau <w@1wt.eu>
Mon, 2 May 2022 14:56:01 +0000 (16:56 +0200)
commit03bd3952a68439b5b540aef61ca7620169b059f3
tree5a6ad7cad5d66fd796e3fd81b87e87c91f9ca8d6
parentb3f0d42a1d3dbebca411ef4f789eb1a4443ff42f
MEDIUM: stream: remove the confusing SF_ADDR_SET flag

This flag is no longer needed now that it must always match the presence
of a destination address on the backend conn_stream. Worse, before previous
patch, if it were to be accidently removed while the address is present, it
could result in a leak of that address since alloc_dst_address() would first
be called to flush it.

Its usage has a long history where addresses were stored in an area shared
with the connection, but as this is no longer the case, there's no reason
for putting this burden onto application-level code that should not focus
on setting obscure flags.

The only place where that made a small difference is in the dequeuing code
in case of queue redistribution, because previously the code would first
clear the flag, and only later when trying to deal with the queue, would
release the address. It's not even certain whether there would exist a
code path going to connect_server() without calling pendconn_dequeue()
first (e.g. retries on queue timeout maybe?).

Now the pendconn_dequeue() code will rely on SF_ASSIGNED to decide to
clear and release the address, since that flag is always set while in
a server's queue, and its clearance implies that we don't want to keep
the address. At least it remains consistent and there's no more risk of
leaking it.
dev/flags/flags.c
include/haproxy/stream-t.h
include/haproxy/stream.h
src/backend.c
src/cli.c
src/dns.c
src/hlua.c
src/http_client.c
src/peers.c
src/queue.c
src/sink.c