<html><body><div style="color:#000; background-color:#fff; font-family:arial, helvetica, sans-serif;font-size:12pt"><div><span>Hi Martin,</span></div><div><br><span></span></div><div><span>Many thanks for your explanation. Now I understand why logging must be protected by the same mutex that is</span></div><div><span>used by the other listening events in bus.c. It is to ensure that while linked_list_t is enumerating the list and invoking</span></div><div><span>log_cb callback, we won't have nodes removed from the linked list by other threads.</span></div><div><span><br></span></div><div><span>You suggested disabling updown plugin or replacing mutex in kernel interface. But the way I see it, this deadlock</span></div><div><span>has a much wider scope. E.g. if kernel interface allows multiple readers, </span><span>it will fix this particular incident but <br></span></div><div><span>deadlock may still occur in other places.
<br></span></div><div><span><br></span></div><div><span>There are 15 mutexes in StrongSwan 4.3.2. The moment one</span><span> of these listening events in bus.c locks <br></span></div><div><span>bus_t.mutex, other threads may be holding one the other mutexes. These</span><span> other threads cannot finish <br></span></div><div><span>their tasks and release the mutexes they are holding because every step of the</span><span> code involve logging. <br></span></div><div><span>Now if the listeners try to acquire the other mutexes, deadlock.</span></div><div><br></div><div><span>Perhaps the loggers should be put in a separate linked list, separated from the dynamic listeners?</span></div><div>Thanks again for your help.</div><div>Simon<br><span></span></div><div><br></div> <div style="font-family: arial,helvetica,sans-serif; font-size: 12pt;"> <div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"> <font face="Arial" size="2"> <hr
size="1"> <b><span style="font-weight: bold;">From:</span></b> Martin Willi <martin@strongswan.org><br> <b><span style="font-weight: bold;">To:</span></b> Simon Chan <simon.chan3@yahoo.ca> <br><b><span style="font-weight: bold;">Cc:</span></b> "users@lists.strongswan.org" <users@lists.strongswan.org> <br> <b><span style="font-weight: bold;">Sent:</span></b> Tuesday, December 6, 2011 12:45:05 AM<br> <b><span style="font-weight: bold;">Subject:</span></b> Re: [strongSwan] what could cause strongswan 4.3.2 to freeze up<br> </font> <br>Hi,<br><br>> If the above is all the mutex is trying to protect, then it would make<br>> my change simpler.<br><br>No, the important part is to protect the list of registered listeners.<br>There are not only loggers, but other dynamically registered listeners<br>that use this interface. Invoking a listener function while it gets<br>unregistered is problematic.<br><br>> The backtrace indicate the
following events:<br>> - thread 9 passed through child_state_change() in bus.c:406 and owned<br>> private_bus_t->mutex<br>> - thread 4 passed through build_address_list() in ike_mobike.c, called <br>> kernel_interface->create_address_enumerator and owned <br>> private_kernel_netlink_net_t->mutex<br>> - thread 9 invoked kernel_interface->get_interface and have to wait for <br>> the private_kernel_netlink_net_t->mutex<br>> - thread 4 called DBG2(DBG_ENC ,"added payload of type %N to message",...)<br>> and have to wait for private_bus_t->mutex<br><br>I see. One option you have is to disable the updown plugin if you don't<br>need it. It is probably the only listener that locks the kernel<br>interface, disabling it will probably solve your issue.<br><br>A second option is to replace the kernel-interface mutex with a<br>read/write-lock, allowing multiple readers to get the
interface list and<br>name. Shouldn't be too hard.<br><br>The third option, making bus_t to invoke listener functions in parallel,<br>would be preferable. But it is very very difficult to implement<br>properly. But that's what we should target for the long term.<br><br>Regards<br>Martin<br><br><br><br><br> </div> </div> </div></body></html>