bryancall opened a new pull request, #13844: URL: https://github.com/apache/trafficserver/pull/13844
Since parallel cert loading ([#12998](https://github.com/apache/trafficserver/pull/12998)), `SSLSecret::getOrLoadSecret()` runs on several `std::thread`s at once during ssl_multicert loading, so `TS_LIFECYCLE_SSL_SECRET_HOOK` handlers now run concurrently. Before that change they ran one at a time on the main thread. The `ssl_secret_load_test` plugin inserts into a global `std::unordered_map` from that hook with no lock. When one loader thread rehashes the map while another is inserting, the heap gets corrupted, and `traffic_server` crashes at startup in `tls_check_dual_cert_selection_plugin` (seen as a fault in `X509_free` under `_prep_ssl_ctx`, with a second loader thread aborting in `free()`). A plugin cannot guard this with a continuation mutex: the loader threads are not EThreads, so `this_ethread()` is null there and `Mutex_lock()` skips the acquire. This change runs the SSL_SECRET hooks under one process-wide lock in `SSLSecret::loadSecret()`. That restores the one-call-at-a-time behavior secret plugins had before. Certificate parsing and `SSL_CTX` setup still run in parallel. The hook docs now say so. Testing: a new `test_net` case sends 4 threads into `getOrLoadSecret()` at once and checks that the hook never has more than one caller. It fails every time without the change and passes with it, and the rest of `test_net` passes. ThreadSanitizer reported the race in the plugin's map on every run of `tls_check_dual_cert_selection_plugin` before the change, with both OpenSSL and BoringSSL builds, and reports none on the loader threads after it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
