race conditions found in kea-dhcp4 MT when perfdhcp packets contain DHO_HOST_NAME
TSAN reported two different race conditions while I was testing #1548 (closed) in MT mode in kea-dhcp4 with a version of perfdhcp that I hacked to send the DHO_HOST_OPTION in client packets. I have verified that these both exist in master without #1548 (closed) (i.e. they have been in the code for quite some time).
The first one is in std::regex() which is called from util::StringSanitzerImpl(). I isloted this enough to be pretty convinced this is in the std::regex implementation (at least under Ubuntu 20.04. I alternated between a local static mutex and a class member mutex in StringSanitizerImpl (see hack_mutex.diff). When hack_mutex_ is a local static the race is avoided, when it is a a member of StringSantizierImpl() the race occurs. I believe this means that the memory in contention resides within std::regex itself. If one undefines USE_REGEX so the code uses regcomp, the race does not occur at all.
The second on is in isc::cryptolink::CryptoLink::initialize(), which is being called when creating the D2Dhcid for NameChangeRequests. I added a mutex and lock to CryptoLink which makes the race condition go away, see crypto.diff. It isn't pretty maybe but it's demonstrative.
These haven't shown up before because most of tests don't send host name (or FQDN) options in client packets. I imagine we would have probably see these same conditions if perfdhcp sent FQDN options in v4 or v6 as well.
I have attached the tsan report, my server config, config.*, and the perfdhcp hack diff.