[asterisk-dev] [Code Review] Remove potential deadlock in call pickup race.

[Russell Bryant]

> On 2011-05-27 17:25:05, Russell Bryant wrote:
> > I think there may be a race condition here.  Can two threads both determine that a channel can be picked up using ast_can_pickup() and then proceed to attempt to attempt a pickup?  I'm not sure if there's a good way to fix it.  Maybe the pickup function just also needs to check for this datastore and bail if it is already there.
> > 
> > I'm also wondering if there could be bad side effects of leaving the datastore on the channel.  It's going to hang around and keep getting moved if transfers and such happen.  Will there _ever_ be a case when it's valid to do a pickup on the same ast_channel twice?  I can't think of one but leaving that data around still doesn't feel right.
> 
> rmudgett wrote:
>     Two threads cannot determine that a channel can be picked up at the same time by ast_can_pickup().  The ast_can_pickup() is a common helper function.  The callers have the channel locked as a precondition and will not release the lock before ast_do_pickup() is called.  Other threads would try to pickup the same call without the lock.
>     
>     The current code does not leave the datastore on the channel.  I thought I would need to leave it to prevent other threads from stealing the just picked up channel away from us.  The code is conditionaled out.  I left it there because I did not want to recreate the comment block if I had to put it back in.  I cannot think of a way a call can be picked up twice either since once a call is picked up the channel state is UP and it cannot/should-not go back to a ringing state.  (It might possibly go to a DOWN state on hangup.  It would not be a good thing to pickup again then anyway.)  Also that datastore is not inheritable.
>
> 
> Alec Davis wrote:
>     Just putting this thought out there, which is not a race between 2 directed pickups.
>     
>     What if the ringing extension is about to be answered by lifting the receiver or to go to voicemail, and someelse tries to do directed pickup of the same ringing extension.
>     Could, at the right time, the directed pickup steal the conventionally answered call?
> 
> rmudgett wrote:
>     If the ringing extension is about to goto voice mail, I don't think what happens would make any difference if the call were normally answered or picked up.  It would either be answered or goto voice mail.
>     
>     I think it would be hard for the user to be able to tell if the call was actually stolen by the pickup.

Oh ok, I see now.  I was the lock and unlock around the code calling ast_can_pickup() so I thought there could be a problem.  Now I see that the channel lock isn't released in the case that the channel was chosen for pickup.


> On 2011-05-27 17:25:05, Russell Bryant wrote:
> > /branches/1.8/include/asterisk/features.h, line 129
> > <https://reviewboard.asterisk.org/r/1234/diff/1/?file=16760#file16760line129>
> >
> >     I know this is pedantic, but can you be more explicit about the return value and say non-zero instead of true here since the return type is int?
> 
> rmudgett wrote:
>     I have used this type of return comment is a bunch of places and it is a typical C idiom.
> 
> rmudgett wrote:
>     Also I want the user to be thinking of boolean usage and not the actual value.

I was just thinking ...

\retval 0 channel can not be picked up
\retval non-zero channel can be picked up

it's not a big deal.  What you have makes the point.


- Russell


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


On 2011-05-26 18:31:19, rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1234/
> -----------------------------------------------------------
> 
> (Updated 2011-05-26 18:31:19)
> 
> 
> Review request for Asterisk Developers, Alec Davis and irroot.
> 
> 
> Summary
> -------
> 
> Fix potential deadlock in ast_do_pickup() with channels chan and target lock and channel container lock.
> 
> This should eliminate the deadlock avoidance code in https://reviewboard.asterisk.org/r/1118/ for issue 18830.
> 
> * Moved can_pickup() to ast_can_pickup() in features.c.
> 
> 
> This addresses bugs 18654 and 18830.
>     https://issues.asterisk.org/view.php?id=18654
>     https://issues.asterisk.org/view.php?id=18830
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/include/asterisk/features.h 321209 
>   /branches/1.8/main/features.c 321209 
>   /branches/1.8/apps/app_directed_pickup.c 321209 
> 
> Diff: https://reviewboard.asterisk.org/r/1234/diff
> 
> 
> Testing
> -------
> 
> Tested a simple call pickup to make sure that it at least still works.
> Needs competing call pickup testing.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

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