talloc & threads in rlm_eap
a.cudbardb at freeradius.org
Thu Jun 19 18:52:46 CEST 2014
On 19 Jun 2014, at 17:39, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
> I'm wondering if we're breaking the talloc() threading restrictions in rlm_eap / main/tls.c somewhere?
> Specifically, I think tls_new_session can be called from multiple threads at the same time, and that calls talloc with a context of "conf" i.e. the module config, which is not per-thread. The talloc docs say each thread must use a separate context (or, presumably, lock).
> I wonder if this is what's triggering the corruption?
Yes, the allocations must be protected with a mutex, or that area of the code should use malloc.
That may explain some of the brokenness with RADSEC too.
If we keep talloc there, the mutex should be in the fr_tls_server_conf_t structure to minimise
> Ditto cbtls_new_session (though OpenSSL locking might protect that) and I think a few other places.
> rlm_eap might be due a substantial cleanup; I find it really really hard to grasp, personally. What do people think?
Yes. There was some work planned for 4.0 that would help, but I think sanitising it now for 3.1 would
also be a good idea.
Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS Development Team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Freeradius-Devel