BUG FOUND IN conn_ctx.c file

[Martin Evans]

Hi,nordic team

In programming code with v2.9.0\nrf\subsys\bluetooth\conn_ctx.c 

and found some bugs of mutex lock.For losing unlock result in lock forever bug.

The selected rows are added by myself.

Best regard

[AMarch01]

My quick take on this, since these functions appear to only be used by hids.c, is that they are intended to be used in pairs. In the function bt_hids_connected() for example,  bt_conn_ctx_alloc() is used to create a new record. If the record is created, then you can assume hids_obj->conn_ctx is locked. 

My first thought was that this one done to stop another call to the function allocating the same record index, while you put data into this record. However, if you unlocked it as you did in allocator presented in your post, then you can be assured that no other thread will get that index, because the act of allocating it marks it in use and "(!ctx->conn && !ctx->data)" will not be true for this index after this. Assuming that you can fill the record and not even use the bt_conn_ctx_release.

This doesn't work if there is the potential of another thread using this record BEFORE it has been completely filled in. I imagine the lock is put in place until all operations are done with the record and then bt_conn_ctx_release is called.

The function bt_conn_ctx_release() is kind of a weird animal. It only releases the lock if the record you were just working with is actually in the list of items. This SHOULD be the case, because if it isn't then you have much bigger problems than the lock being left on. 

I imagine the other functions maintain pair locking while the user is working with the record.