[bsinou]

Port of #29 to dev, rewritten.

Issue

In ratelimit_is_address_limited, ur_addr_map_get runs without rate_limit_main_mutex, concurrently with inserts from other threads and with the pruning, which frees entries (addr_list_foreach_del_condition). A thread can read the map while it changes, or use an entry that was just freed.

Change

Take rate_limit_main_mutex before the lookup and hold it until the entry is no longer used: on the existing-entry paths it is released after the entry mutex, and the new-entry path reuses it for the insert instead of locking again. Lock order is main, then entry, then allowlist, and nothing takes them in another order.

#29 could not be ported as is: it unlocked right after the lookup (the entry could still be freed), unlocked a second time on the rate-limited path, and never unlocked when the address was new, which deadlocks on the first 401 from a new IP.

Testing

Built on Ubuntu 24.04 as in CI: make check passes, and the TCP, TLS, UDP and DTLS client tests pass.

The "rate limit by IP" client test reports FAIL on dev as well, without failing the job: it relies on the default limit of 1000 401 responses per window, which the test never reaches, and exit $? after echo FAIL exits 0. I ran the server by hand with --401-req-limit=3 instead: valid credentials are served, the address is rate limited after 3 responses, and the server stays responsive, the same as on dev.

[z-dule]

This looks like it would work, but having nested labels inside an else is terrible practice!