BUG/MINOR: guid/server: ensure thread-safety on GUID insert/delete

Since 3.0, it is possible to assign a GUID to proxies, listeners and
servers. These objects are stored in a global tree guid_tree.

Proxies and listeners are static. However, servers may be added or
deleted at runtime, which imply that guid_tree must be protected. Fix
this by declaring a read-write lock to protect tree access.

For now, only guid_insert() and guid_remove() are protected using a
write lock. Outside of these, GUID tree is not accessed at runtime. If
server CLI commands are extended to support GUID as server identifier,
lookup operation should be extended with a read lock protection.

Note that during stat-file preloading, GUID tree is accessed for lookup.
However, as it is performed on startup which is single threaded, there
is no need for lock here. A BUG_ON() has been added to ensure this
precondition remains true.

This bug could caused a segfault when using dynamic servers with GUID.
However, it was never reproduced for now.

This must be backported up to 3.0. To avoid a conflict issue, the
previous cleanup patch can be merged before it.
This commit is contained in:
Amaury Denoyelle
2024-11-07 11:08:40 +01:00
parent b70880cdc9
commit 8e0e7d9d1a
4 changed files with 20 additions and 0 deletions

View File

@@ -1,7 +1,11 @@
#ifndef _HAPROXY_GUID_H
#define _HAPROXY_GUID_H
#include <haproxy/api-t.h>
#include <haproxy/guid-t.h>
#include <haproxy/thread-t.h>
__decl_thread(extern HA_RWLOCK_T guid_lock);
void guid_init(struct guid_node *node);
int guid_insert(enum obj_type *obj_type, const char *uid, char **errmsg);

View File

@@ -205,6 +205,7 @@ enum lock_label {
OCSP_LOCK,
QC_CID_LOCK,
CACHE_LOCK,
GUID_LOCK,
OTHER_LOCK,
/* WT: make sure never to use these ones outside of development,
* we need them for lock profiling!