dax: fix race condition on the tuning buffer - #11056
Conversation
It is necessary cause p_dax is used in dax.c now. Signed-off-by: Jun Lai <jun.lai@dolby.com>
|
Can one of the admins verify this patch?
|
0749fcc to
95f5201
Compare
While the tuning buffer is being updated, it may also be being used simultaneously in the process thread. Signed-off-by: Jun Lai <jun.lai@dolby.com>
95f5201 to
ab9a656
Compare
|
@lrudyX good to merge, I'm pretty sure not tested by CI. |
No, It was not build and run with any test. (Scheduler ignores this PR until "test this please" command) The CI pipeline is stopped at the moment due to cmake upgrade. |
kv2019i
left a comment
kv2019i
left a comment
There was a problem hiding this comment.
Looks ok. Please do @checkupup check my note on use of spinlocks. Not a blocker for this PR, but something for future.
| struct dax_adapter_data *adapter_data = module_get_private_data(mod); | ||
| struct sof_dax *dax_ctx = &adapter_data->dax_ctx; | ||
| struct dax_buffer old_tuning_buf = {0}; | ||
| k_spinlock_key_t key; |
There was a problem hiding this comment.
Note: use of spinlocks will prevent to run this module in user-space. This is not a blocker for this PR (as spinlocks are used elsewhere in dax manager), but FYI that we've been migrating other audio modules to use mutex locking instead. In this particular case, moving to a mutex is trickier as mutex won't disable interrupts like spinlocks do. With a mutex, you would need to take the lock in sof_dax_process() for code that uses the tuning_data_object (this protects for the case when IPC to change tuning is running and a new LL tick preempts the IPC thread -> one needs to ensure sof_dax_process() cannot proceed before new tuning data is in place). With spinlocks this scenario won't happen as LL tick preemption cannot happen while the spinlock is held.
There was a problem hiding this comment.
Thanks vehmanen, I am considering to move all exclusive accesses from spinlocks to mutexs in future.
6 participants
No description provided.