[asterisk-dev] [Code Review] another take on the asyc_goto lock inversion issue.

[kkm]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1275/#review3755
-----------------------------------------------------------


Quickly tested here and it works correctly and does not cause any problems (the function is nominally hit with chan->pbx==NULL when a callee transfers the caller with SIP REFER).

Looks much safer a fix than mine, indeed! Thanks.

- kkm


On 2011-06-17 10:46:36, David Vossel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1275/
> -----------------------------------------------------------
> 
> (Updated 2011-06-17 10:46:36)
> 
> 
> Review request for Asterisk Developers and kkm.
> 
> 
> Summary
> -------
> 
> This is in response to review 1274.  kkm identified an issue with async_goto, and as I was reviewing it I realized the problem is much deeper than I can easily comment and give direction on in the review.  It wasn't much code so I just wrote what I was thinking instead.
> 
> We can not hold the "chan" lock while doing the masquerade, the explicit goto on the tmp chan, or the channel alloc.  Nearly the entire function is wrong.  Instead we need to get the channel lock, store off information about the channel that we need, and then let the channel lock go for the remainder of the function.
> 
> 
> This addresses bug ASTERISK-18031.
>     https://issues.asterisk.org/jira/browse/ASTERISK-18031
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/include/asterisk/pbx.h 324047 
>   /branches/1.8/main/pbx.c 324047 
> 
> Diff: https://reviewboard.asterisk.org/r/1275/diff
> 
> 
> Testing
> -------
> 
> I have not tested this.
> 
> 
> Thanks,
> 
> David
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110618/5e797775/attachment.htm>