rlm_cache locking (or not)

[Arran Cudbard-Bell]

On 26 Oct 2012, at 16:01, Phil Mayers <p.mayers at IMPERIAL.AC.UK> wrote:

> On 26/10/12 15:34, Phil Mayers wrote:
> 
>> I was about to say "that worked like a charm" then radiusd segfaulted :o(
>> 
>> I'll try to get a core dump.
>> 
> 
> Ugh. Horrible pointer corruption; little useful in the backtrace I'm afraid, but the various pointers were invalid by stack frame #5
> 
> #0  0x000000357f630215 in raise () from /lib64/libc.so.6
> #1  0x000000357f631cc0 in abort () from /lib64/libc.so.6
> #2  0x000000357f66a7fb in __libc_message () from /lib64/libc.so.6
> #3  0x000000357f671ce2 in _int_free () from /lib64/libc.so.6
> #4  0x000000357f67590c in free () from /lib64/libc.so.6
> #5  0x00002aaaad3444ac in cache_entry_free (data=0xc00aa0) at rlm_cache.c:77
> #6  0x00000031bb212eac in rbtree_delete (tree=0xbd5530, Z=0xbfd050) at rbtree.c:412
> #7  0x00000031bb21302b in rbtree_deletebydata (tree=0xbd5530, data=<value optimized out>) at rbtree.c:461
> #8  0x00002aaaad344465 in cache_find (inst=0xbd4eb0, request=0x2aaab8001150, key=0x41e013c0 "172.16.250.14.Stop.508aa231/dc:2b:61:b0:cd:7c/653919") at rlm_cache.c:164
> #9  0x00002aaaad344652 in cache_it (instance=0xbd4eb0, request=0x2aaab8001150) at rlm_cache.c:567
> #10 0x000000000041c951 in call_modsingle (component=3, c=<value optimized out>, request=0x2aaab8001150) at modcall.c:304
> 
> 
> Looking at the code, I'm not entirely sure it's thread-safe; I don't see any locking around anything. What's to stop cache_entry_free running at the same time as the node is being accessed in another thread? Or the rbtree being corrupted?
> 
> I've had to roll the change back, so I can't give more details at the moment.


I've only ever tested it in debugging mode, which of course runs single threaded... I'd assumed that as Alan wrote the code there had to be locks associated with the rbtree but no... obviously not.

Quick fix would be to change type to RLM_TYPE_THREAD_UNSAFE in the module_t struct, then it'll go through modcall_single.

-Arran