[OpenSIPS-Devel] tm hash deadlock patch

[Bogdan-Andrei Iancu]

Hi Eric,

Thank you for your patch and first of all for spotting the problem - a 
real tricky one.

But as Vlad explained you on IRC, the patch has a problem as it breaks 
the atomic "test and set" for "transaction lookup and creation".

Also, the callback cannot be moved after the transaction creation 
(actually cloning the request in transaction) as several module rely on 
this to do last minute parsing, parsing to be cloned in transaction.

What I would find as a clean solution is to split the callback for 
TMCB_REQUEST_IN in TMCB_REQUEST_IN (as it is, under lock, for special 
cases) and TMCB_REQUEST_POST_IN to be called after transaction is 
created, outside the lock, for modules interested just in the event "new 
transaction"

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 02/28/2013 07:33 PM, Eric Tamme wrote:
> We found that initial request callbacks are called with a lock on the 
> tm hash row so any callback that generates a new transaction, in our 
> example the pua module, can generate a hash for the new transaction 
> with the same key as the locked row thus creating a deadlock.
>
> We modified the code to create a lock on the cell when t_newtran() 
> calls new_t and release the hash lock within new_t so that the 
> callbacks are called with a cell lock, not a row lock.  This looks l
>
> Please review the attached patch.  The patch was made on a 1.6.4 code 
> base.  Let me know if you have any thoughts or concerns.
>
> -Eric
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20130305/43aef676/attachment.htm>