On 23 Aug 2019, at 14:34, Eric Covener <cove...@gmail.com> wrote: > I have a question in this area, not necessarily a result of this commit. > > I have been playing with a new crypto provider, in a non-DSO build, > intended to be used with httpd. > > The provider does have both an initialization and termination API. > > My issue is a result of the "rootp" being used for the driver hashmap > but "pconf" (in the httpd/mod_session_crypto case) being passed to the > drivers init() function the first time it's loaded. This means at > graceful restart, cleanups registered by the drivers init() function > will run, but apr_crypto_term will not, and the next call to get the > driver will not re-run the init(). > > Making the lifetimes match either way fixes my test -- either moving > the "rootp" stuff to DSO-only for apr_crypto_init or by passing > "rootp" to the DRIVER_LOAD macro for non-DSO init. > > Any opinions?
Pool lifetime issues have been fixed in the apu_dso_init() function, most specifically you can now run the init, then clean up the pool, then run init a second time, then clean up the pool the second time, and this will work. Previously init could only ever be called once, but practically it was being called over and over again by every httpd module that touches DSO (sql, etc). This fix isn’t enough - the same pool lifetime bug exists in apu_dso_load(), and each DSO’s init function. The fix that will work is implement the same strategy for pool cleanup implemented in apu_dso_init() everywhere else, but this means lots of repetition. I have wanted to implement a generic solution to this, but have not had time to figure that out. Regards, Graham —
smime.p7s
Description: S/MIME cryptographic signature
