rlm_cache locking (or not)

[Phil Mayers]

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.