From 9b6d17e423da138ea7fd190ae366580c539dceca Mon Sep 17 00:00:00 2001 From: Matt Caswell Date: Mon, 30 Aug 2021 15:54:22 +0100 Subject: [PATCH] Add a warning about locking in the child provider callback docs The child provider callbacks can hold the store lock. In order to avoid deadlocks we require that the callback implementations don't themselves call functions that may aquire those locks. Reviewed-by: Tomas Mraz Reviewed-by: Paul Dale (Merged from https://github.com/openssl/openssl/pull/16469) --- doc/man7/provider-base.pod | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/man7/provider-base.pod b/doc/man7/provider-base.pod index 92c167638b..ac197accca 100644 --- a/doc/man7/provider-base.pod +++ b/doc/man7/provider-base.pod @@ -123,7 +123,7 @@ provider-base All "functions" mentioned here are passed as function pointers between F and the provider in B arrays, in the call of the provider initialization function. See L -for a description of the initialization function. +for a description of the initialization function. They are known as "upcalls". All these "functions" have a corresponding function type definition named B, and a helper function to retrieve the @@ -328,7 +328,9 @@ provider_register_child_cb() registers callbacks for being informed about the loading and unloading of providers in the application's library context. I is this provider's handle and I is this provider's data that will be passed back to the callbacks. It returns 1 on success or 0 -otherwise. +otherwise. These callbacks may be called while holding locks in libcrypto. In +order to avoid deadlocks the callback implementation must not be long running +and must not call other OpenSSL API functions or upcalls. I is a callback that will be called when a new provider is loaded into the application's library context. It is also called for any providers that -- 2.34.1