app_rpt.c, rpt_cli.c, rpt_manager.c: Add missing mutex_lock()

[mkmer]

It appears these calls should be mutex_locked.

[mkmer]

While reviewing code that generated this PR, I notice this:

app_rpt/apps/app_rpt/rpt_link.c

Lines 175 to 185 in 7b97e6c

	void rpt_qwrite(struct rpt_link *l, struct ast_frame *f)
	{
	struct ast_frame *f1;
	if (!l->chan)
	return;
	f1 = ast_frdup(f);
	memset(&f1->frame_list, 0, sizeof(f1->frame_list));
	AST_LIST_INSERT_TAIL(&l->textq, f1, frame_list);
	return;
	}

I'm not positive, but I think we should be locked when adding to the list? Or maybe when calling rpt_qwrite()?

[InterLinked1]

While reviewing code that generated this PR, I notice this:

app_rpt/apps/app_rpt/rpt_link.c

Lines 175 to 185 in 7b97e6c

	void rpt_qwrite(struct rpt_link *l, struct ast_frame *f)
	{
	struct ast_frame *f1;
	if (!l->chan)
	return;
	f1 = ast_frdup(f);
	memset(&f1->frame_list, 0, sizeof(f1->frame_list));
	AST_LIST_INSERT_TAIL(&l->textq, f1, frame_list);
	return;
	}

I'm not positive, but I think we should be locked when adding to the list? Or maybe when calling rpt_qwrite()?

Ah, that's a good point. It looks like it's using a linked list without a lock so some kind of locking does seem needed.

[Allan-N]

I'm approving this change as an incremental improvement. But, we really need to take a step back and review/analyze/update all of the logic around myrpt and the associated links.

Why? If you look at the call to __mklnklist inside the periodic_process_links() function you will see we are passing myrpt and l. Even if we lock myrpt one can/should ask whether l is still valid as it is captured from myrpt->links.next at the top of the function and advanced at the end of the while() loop without holding any locks.