Skip to content

dax: fix race condition on the tuning buffer - #11056

Open
checkupup wants to merge 2 commits into
thesofproject:mainfrom
checkupup:main_dax_fixes
Open

dax: fix race condition on the tuning buffer#11056
checkupup wants to merge 2 commits into
thesofproject:mainfrom
checkupup:main_dax_fixes

Conversation

@checkupup

@checkupupcheckupup commented Aug 3, 2026

Copy link
Copy Markdown
Contributor

No description provided.

@checkupupJun Lai
dax: update p_dax pointer state on mock version
9fd06e9
It is necessary cause p_dax is used in dax.c now.
Signed-off-by: Jun Lai <jun.lai@dolby.com>
@sofci

sofci commented Aug 3, 2026

Copy link
Copy Markdown
Collaborator

Can one of the admins verify this patch?

reply test this please to run this test once

lyakh
lyakh reviewed Aug 4, 2026
View reviewed changes
Comment threadsrc/audio/module_adapter/module/dolby/dax.c Outdated
@checkupup
checkupupforce-pushed the main_dax_fixes branch 2 times, most recently from 0749fcc to 95f5201CompareAugust 5, 2026 06:29
@checkupup
checkupup marked this pull request as ready for review August 6, 2026 06:35
lyakh
lyakh reviewed Aug 6, 2026
View reviewed changes
Comment threadsrc/audio/module_adapter/module/dolby/dax_mock.c
Comment threadsrc/audio/module_adapter/module/dolby/dax.c Outdated
Comment threadsrc/audio/module_adapter/module/dolby/dax.c Outdated
Comment threadsrc/audio/module_adapter/module/dolby/dax.c
@checkupupJun Lai
dax: fix race condition on the tuning buffer
ab9a656
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>
@lgirdwood

lgirdwood commented Aug 10, 2026

Copy link
Copy Markdown
Member

@lrudyX good to merge, I'm pretty sure not tested by CI.

@lrudyX

lrudyX commented Aug 11, 2026

Copy link
Copy Markdown

@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
kv2019i approved these changes Aug 13, 2026
View reviewed changes

@kv2019ikv2019i left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks ok. Please do @checkupup check my note on use of spinlocks. Not a blocker for this PR, but something for future.

Comment threadsrc/audio/module_adapter/module/dolby/dax.c
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;

@kv2019ikv2019iAug 13, 2026

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@checkupupcheckupupAug 14, 2026

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks vehmanen, I am considering to move all exclusive accesses from spinlocks to mutexs in future.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@lyakhlyakhlyakh left review comments
@lgirdwoodlgirdwoodlgirdwood approved these changes
@kv2019ikv2019ikv2019i approved these changes
@plbossartplbossartAwaiting requested review from plbossartplbossart is a code owner
@mmaka1mmaka1Awaiting requested review from mmaka1mmaka1 is a code owner
@lbetlejlbetlejAwaiting requested review from lbetlejlbetlej is a code owner
@dbalutadbalutaAwaiting requested review from dbalutadbaluta is a code owner

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

6 participants

@checkupup@sofci@lgirdwood@lrudyX@lyakh@kv2019i