Describe the bug

There are several cases where a single function may access multiple instances.

For example try_change_dialing_call_to_alerting may only have the inst parameter mutex locked, but then accesses gtbs without locking GTBS.

Similarly write_call_cp may lock gtbs but then lookup and access a specific TBS instance without a lock.

The first fix required is to lock the other instances when we access them. However this may lead for a deadlock:

Since try_change_dialing_call_to_alerting may be called from any thread (directly called via an API function), we may end up in a situation where thread_a locks tbs[0] and thread_b locks gtbs, and then thread_a will attempt to lock gtbs while thread_b attempts to lock tbs[1].

Today, since we are using either K_NO_WAIT or MUTEX_TIMEOUT this isn't an actual deadlock, as we will always return, but we should consider making these attempt to lock for longer to provide a smoother solution.

One suggestion to handle this is to always lock GTBS first in each function that requires access to any instance. If GTBS is always locked first, then no 2 threads will ever be able to attempt to lock any other TBS mutex, thus preventing deadlocks, even if the mutex locks are using K_FOREVER

Regression

• This is a regression.

Steps to reproduce

No response

Relevant log output

Impact

Annoyance – Minor irritation; no significant impact on usability or functionality.

Environment

No response

Additional Context

No response