-
Notifications
You must be signed in to change notification settings - Fork 8.3k
data race in OPENSSL_sk_num #80160
Description
I faced a sanitazer report in the CI
full report: https://s3.amazonaws.com/clickhouse-test-reports/PRs/79963/1cde959f33ad5a23e68a0f52365000c2da5455df//integration_tests_tsan_2_6/integration_run_parallel4_0.log
read write stack: https://pastila.nl/?001166e3/2c2a085d64d5295b50a2d12dcf1fc1a5#h0aJA5qyZg7fiZkrXJC2EQ==
As I read here openssl/openssl#24480
openssl/openssl#24480 (comment)
An SSL_CTX object should not be changed after it is used to create any SSL objects or from multiple threads concurrently, since the implementation does not provide serialization of access for these cases.
And the load operations mutate the SSL_CTX object, by adding certificate location to an internal list.
The appropriate approach here is to call all the mutation functions for the SSL_CTX objects prior to passing to threads for use, so that the shared object can be used in an immutable fashion.
I'm not sure that Clickhouse follows this rule.
May be we need to reorganize our Storages initialization. Now, the one storage is adding certs, other is already firing the requests over ssl.