talloc & threads in rlm_eap

[Arran Cudbard-Bell]

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 
contention.

> 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...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20140619/d4f35537/attachment.pgp>