[Asterisk-code-review] res_pjsip_outbound_registration.c: Use our own scheduler and other s... (asterisk[16])

George Joseph asteriskteam at digium.com
Thu Nov 5 07:32:35 CST 2020


George Joseph has posted comments on this change. ( https://gerrit.asterisk.org/c/asterisk/+/15130 )

Change subject: res_pjsip_outbound_registration.c:  Use our own scheduler and other stuff
......................................................................


Patch Set 3:

(2 comments)

https://gerrit.asterisk.org/c/asterisk/+/15130/3/res/res_pjsip_outbound_registration.c 
File res/res_pjsip_outbound_registration.c:

https://gerrit.asterisk.org/c/asterisk/+/15130/3/res/res_pjsip_outbound_registration.c@535 
PS3, Line 535: 		ast_sip_sched_task_cancel(client_state->sched_task);
             : 		ao2_cleanup(client_state->sched_task);
             : 		client_state->sched_task = NULL;
> this removes the task, and potential destroys the task object. If so then at that time the task_data object is also de-referenced. Does that mean client_state here could possibly be "cleaned up"/freed also? Thus causing badness when calling client_state->... next?

ast_sip_sched_task_cancel only removes the reference that was added when the task was scheduled.  cancel_registration is always called while at least "state" is holding a reference. if you look at where it's used, there are always usages of client_state after the call to cancel_registration.  There's just no way for client_state to be destroyed here.


https://gerrit.asterisk.org/c/asterisk/+/15130/3/res/res_pjsip_outbound_registration.c@534 
PS3, Line 534: 	if (client_state->sched_task) {
             : 		ast_sip_sched_task_cancel(client_state->sched_task);
             : 		ao2_cleanup(client_state->sched_task);
             : 		client_state->sched_task = NULL;
             : 	}
> Should this be surrounded by a lock? Is it possible for another thread to enter here while it's being canceled by another thread? If so then without a lock it could be canceled twice.

cancel_registration is protected by the fact that it's always called from the registration's serializer.



-- 
To view, visit https://gerrit.asterisk.org/c/asterisk/+/15130
To unsubscribe, or for help writing mail filters, visit https://gerrit.asterisk.org/settings

Gerrit-Project: asterisk
Gerrit-Branch: 16
Gerrit-Change-Id: I4534a0fc78c7cb69f23b7b449dda9748c90daca2
Gerrit-Change-Number: 15130
Gerrit-PatchSet: 3
Gerrit-Owner: George Joseph <gjoseph at digium.com>
Gerrit-Reviewer: Friendly Automation
Gerrit-Reviewer: Kevin Harwell <kharwell at digium.com>
Gerrit-Comment-Date: Thu, 05 Nov 2020 13:32:35 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Kevin Harwell <kharwell at digium.com>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20201105/130bbbdf/attachment.html>


More information about the asterisk-code-review mailing list