-
Notifications
You must be signed in to change notification settings - Fork 5k
Fix OpenSSL stores refreshing too frequently #102838
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones |
/backport-to release/8.0-staging |
/backport to release/8.0-staging |
Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/13706777103 |
@bartonjs backporting to "release/8.0-staging" failed, the patch most likely resulted in conflicts: $ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch
Applying: Fix OpenSSL store refreshing
Using index info to reconstruct a base tree...
M src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X509Certificates/OpenSslCachedSystemStoreProvider.cs
Falling back to patching base and 3-way merge...
Auto-merging src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X509Certificates/OpenSslCachedSystemStoreProvider.cs
CONFLICT (content): Merge conflict in src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X509Certificates/OpenSslCachedSystemStoreProvider.cs
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Patch failed at 0001 Fix OpenSSL store refreshing
Error: The process '/usr/bin/git' failed with exit code 128 Please backport manually! |
Background: OpenSSL stores refresh themselves, either on-demand or periodically (assumed stale). The way it was written, a thread checks to see if the store needs to be refreshed. If it does, it takes a lock, and refreshes it.
If you have multiple threads waiting on the lock, then the lock is released, the next thread will proceed. However, the "does the store need to be refreshed?" information is stored in a local. So after a thread has acquired the lock, it appears that the store needs to be refreshed. So each thread that arrives at the lock patiently waits its turn, thinks the store needs to be refreshed, and refreshes it.
This refreshes the locals after the lock has been take to see if another thread updated the information after the thread got a hold of the lock.