-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bluetooth: Host: Ensure conn_ready access is thread safe #83700
Bluetooth: Host: Ensure conn_ready access is thread safe #83700
Conversation
* The `bt_dev.le.conn_ready` list is accessed by the tx_processor which runs in a workqueue, but `bt_conn_data_ready` can be called from different threads so we need to make sure that nothing will trigger a context switch while we are manipulating the list since sys_slist_*() functions are not thread safe. * This only happens if call to `bt_conn_data_ready` is performed from a preemptive task which can happen depending on the application. Signed-off-by: Yago Fontoura do Rosario <[email protected]>
* which runs in a workqueue, but `bt_conn_data_ready` can be called | ||
* from different threads so we need to make sure that nothing will | ||
* trigger a thread switch while we are manipulating the list since | ||
* sys_slist_*() functions are not thread safe. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
get_conn_ready
also manipulates the list by doing
if (should_stop_tx(conn)) {
/* Move reference off the list and into the `conn` variable. */
__maybe_unused sys_snode_t *s = sys_slist_get(&bt_dev.le.conn_ready);
__ASSERT_NO_MSG(s == node);
(void)atomic_set(&conn->_conn_ready_lock, 0);
/* Append connection to list if it still has data */
if (conn->has_data(conn)) {
LOG_DBG("appending %p to back of TX queue", conn);
bt_conn_data_ready(conn);
}
return conn;
}
since sys_slist_get
pops the list. Should this also be guarded by a k_sched_lock
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That one is okay, because get_conn_ready
is called on bt_conn_tx_processor
which is executed in the system workqueue. Since the system workqueue is being executed at a cooperative priority, we don't need it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we don't need it here.
for now :D
@Yagoor this is failing in main, please have a look:
|
bt_dev.le.conn_ready
list is accessed by the tx_processorwhich runs in a workqueue, but
bt_conn_data_ready
can be calledfrom different threads so we need to make sure that nothing will
trigger a context switch while we are manipulating the list since
sys_slist_*() functions are not thread safe.
bt_conn_data_ready
is performedfrom a preemptive task which can happen depending on the
application.