Data race in drcontainers/hashtable.c during table resize

Created by: Carrotman42

This appears to have existed since hashtables automatically grew in size (https://github.com/DynamoRIO/dynamorio/commit/22991f385eec3907969ed492591a6c4c8751a489).

The synch lock is not properly held in hash_key when it reads table->bits: https://github.com/DynamoRIO/dynamorio/blob/f0699d6e58703c96102c26fffee7fb1d89537691/ext/drcontainers/hashtable.c#L182

(hash_key is called in places like hashtable_lookup without holding the lock:

https://github.com/DynamoRIO/dynamorio/blob/f0699d6e58703c96102c26fffee7fb1d89537691/ext/drcontainers/hashtable.c#L267-L274

)

And this races with the table->table_bits++ (and the entire rehashing of the table) in hashtable_check_for_resize:

https://github.com/DynamoRIO/dynamorio/blob/f0699d6e58703c96102c26fffee7fb1d89537691/ext/drcontainers/hashtable.c#L286-L301

The easiest fix I see is to require that the hashtable lock be held while calling hash_key. While this reduces parallelism for the hash function, the table_bits are required input values to the HASH_STRING and HASH_STRING_NOCASE hashes (so we have to prevent the table_bits from changing underneath) and the HASH_INTPTR is so simple I don't think there's any real parallelism loss there. My only perf concern would be that users of HASH_CUSTOM may be expecting parallelism if they have an expensive hash operation.

I propose we move forward with rearranging locks in the function until we find out the perf hit affects someone.