[Asterisk-code-review] various: fix and test a double deref on a scheduled delete of an exec... (asterisk[16])

[Kevin Harwell]

Attention is currently required from: Michael Bradeen, Joshua Colp.
Kevin Harwell has posted comments on this change. ( https://gerrit.asterisk.org/c/asterisk/+/17644 )

Change subject: various: fix and test a double deref on a scheduled delete of an executing call back.
......................................................................


Patch Set 7: Code-Review-1

(12 comments)

File include/asterisk/sched.h:

https://gerrit.asterisk.org/c/asterisk/+/17644/comment/9c882918_150db312 
PS7, Line 75:  * Only calls unref function if the delete succeeded.
I think this could use additional clarification:

"Only calls the unref function if the task is actually deleted by ast_sched_del_nonrunning. If a failure occurs, or the task is currently running and not rescheduled the unref function is not called."


https://gerrit.asterisk.org/c/asterisk/+/17644/comment/d748251b_fd1b7d23 
PS7, Line 315: * \retval -2 event was running and not rescheduled
Reword this a bit to say something like "-2 event was running, but deleted via non rescheduling.


File main/sched.c:

https://gerrit.asterisk.org/c/asterisk/+/17644/comment/5318d478_513a151f 
PS2, Line 658: 			sched_release(con, s);
"s" gets freed in sched_release, and should be set to NULL after calling sched_release since "s" is checked for NULL later in this function.


File main/sched.c:

https://gerrit.asterisk.org/c/asterisk/+/17644/comment/1dce11b5_f7d37f1a 
PS7, Line 666: 			/* This was not rescheduled so the caller of ast_sched_del can not remove any
             : 			 * references as they already were.
             : 			 */
I think this comment can be deleted. To me it is a bit out of context here as the scheduler has no knowledge of references, and does not manage user resources.


https://gerrit.asterisk.org/c/asterisk/+/17644/comment/1edb6e80_fcf1ab19 
PS7, Line 673: 			 * it's destruction to us
s/it's/its


https://gerrit.asterisk.org/c/asterisk/+/17644/comment/7f38918c_b1855b50 
PS7, Line 688: 	if (!s && *last_id != id) {
             : 		ast_debug(1, "Attempted to delete nonexistent schedule entry %d!\n", id);
             : 		/* Removing nonexistent schedule entry shouldn't trigger assert (it was enabled in DEV_MODE);
             : 		 * because in many places entries is deleted without having valid id. */
             : 		*last_id = id;
             : 		return -1;
             : 	} else if (!s) {
             : 		return -1;
             : 	}
             : 
             : 	return res;
When you set "s" to NULL above this might need to be reworked as this function will now always return -1.


File tests/test_sched.c:

https://gerrit.asterisk.org/c/asterisk/+/17644/comment/1f904c45_ac4d34d7 
PS2, Line 366: 	usleep(3000);
usleep can be interrupted, so this probably needs to be in a loop to ensure the full 3 seconds passes.

Example using nanosleep:

; one second pause/delay
struct timespec delay = { 1, 0 };

while (nanosleep(&delay, &delay));


https://gerrit.asterisk.org/c/asterisk/+/17644/comment/769f2b59_f07e36ec 
PS2, Line 406: 		return AST_TEST_FAIL;
> obj is leaked
obj still leaked.


https://gerrit.asterisk.org/c/asterisk/+/17644/comment/7454c646_d4fb79e2 
PS2, Line 412: 		return AST_TEST_FAIL;
> obj is leaked
obj still leaked.


File tests/test_sched.c:

https://gerrit.asterisk.org/c/asterisk/+/17644/comment/fa6f8671_f068e2bb 
PS7, Line 405: 	ao2_ref(obj, +1);
If you move this to just before sched_add then you'll no longer leak "obj" in the below off nominal paths.


https://gerrit.asterisk.org/c/asterisk/+/17644/comment/8c86e2d3_4b64b355 
PS7, Line 423: 	ao2_bump(obj);
If you move the add ref above this can become ao2_ref(obj, +2);

If you do that make sure to also add/keep the comment why the additional ref is needed.


https://gerrit.asterisk.org/c/asterisk/+/17644/comment/aea91a47_b4b2ae00 
PS7, Line 426: 		while(ao2_ref(obj, -1) > 1);
If this fails you know you have 3 additional refs currently, so ao2_ref(obj, -3) should be sufficient. Also, to me it makes ref tracking more clear.



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

Gerrit-Project: asterisk
Gerrit-Branch: 16
Gerrit-Change-Id: Icfb16b3acbc29cf5b4cef74183f7531caaefe21d
Gerrit-Change-Number: 17644
Gerrit-PatchSet: 7
Gerrit-Owner: Michael Bradeen <mbradeen at sangoma.com>
Gerrit-Reviewer: Friendly Automation
Gerrit-Reviewer: Joshua Colp <jcolp at sangoma.com>
Gerrit-Reviewer: Kevin Harwell <kharwell at digium.com>
Gerrit-Reviewer: Sean Bright <sean at seanbright.com>
Gerrit-Attention: Michael Bradeen <mbradeen at sangoma.com>
Gerrit-Attention: Joshua Colp <jcolp at sangoma.com>
Gerrit-Comment-Date: Thu, 06 Jan 2022 19:10:58 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Comment-In-Reply-To: Joshua Colp <jcolp at sangoma.com>
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-code-review/attachments/20220106/9f320eca/attachment.html>