rlm_cache locking (or not)
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.
On 26 Oct 2012, at 16:01, Phil Mayers <p.mayers@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
Arran Cudbard-Bell wrote:
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.
No. The rbtree API just does trees. It doesn't do locks.
Quick fix would be to change type to RLM_TYPE_THREAD_UNSAFE in the module_t struct, then it'll go through modcall_single.
Yes. Alan DeKok.
On 26/10/12 16:28, Arran Cudbard-Bell wrote:
Quick fix would be to change type to RLM_TYPE_THREAD_UNSAFE in the module_t struct, then it'll go through modcall_single.
Ah, I didn't think of that; I've already done this: https://github.com/philmayers/freeradius-server/commit/2250dc653203a43446703... :o/ Oh well!
On 26 Oct 2012, at 16:56, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 26/10/12 16:28, Arran Cudbard-Bell wrote:
Quick fix would be to change type to RLM_TYPE_THREAD_UNSAFE in the module_t struct, then it'll go through modcall_single.
Ah, I didn't think of that; I've already done this:
https://github.com/philmayers/freeradius-server/commit/2250dc653203a43446703...
:o/
Oh well!
That's better for the general case, as it's possible you'll have ldap/sql xlat expansions being done through the module which would benefit from multithreadedness. Please send a pull request :) -Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 26/10/12 17:20, Arran Cudbard-Bell wrote:
On 26 Oct 2012, at 16:56, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 26/10/12 16:28, Arran Cudbard-Bell wrote:
Quick fix would be to change type to RLM_TYPE_THREAD_UNSAFE in the module_t struct, then it'll go through modcall_single.
Ah, I didn't think of that; I've already done this:
https://github.com/philmayers/freeradius-server/commit/2250dc653203a43446703...
:o/
Oh well!
That's better for the general case, as it's possible you'll have ldap/sql xlat expansions being done through the module which would benefit from multithreadedness.
Please send a pull request :)
Will do, let me run it for a couple of hours first though, check it doesn't explode or something!
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Phil Mayers