Skip to content

fast-get: Fix shared data usage by multiple callers #10484

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.

Sign up for GitHub

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

Merged
kv2019i merged 1 commit into from
Jan 16, 2026
+2 −1
Merged

fast-get: Fix shared data usage by multiple callers #10484

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion zephyr/lib/fast-get.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -117,12 +117,13 @@ const void *z_impl_fast_get(struct k_heap *heap, const void *dram_ptr, size_t si
goto out;
}

ret = sof_heap_alloc(heap, SOF_MEM_FLAG_USER, size, 0);
ret = sof_heap_alloc(heap, SOF_MEM_FLAG_USER, size, PLATFORM_DCACHE_ALIGN);
if (!ret)
goto out;
entry->size = size;
entry->sram_ptr = ret;
memcpy_s(entry->sram_ptr, entry->size, dram_ptr, size);
dcache_writeback_region((__sparse_force void __sparse_cache *)entry->sram_ptr, size);
Copy link
Collaborator

@kv2019i kv2019i Jan 15, 2026

Choose a reason for hiding this comment

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

Can you @jsarha and @lyakh comment on the semantics? This seems correct in the sense to ensure the memcpy actually reaches sram, but I'm not sure of the fast_get API semantics whether this is correct usage (iow are there other places that would need modifications if used by multiple cores).

Copy link
Collaborator

@lyakh lyakh Jan 16, 2026

Choose a reason for hiding this comment

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

oh, yes, this looks correct and an oversight in the original implementation - thanks @serhiy-katsyuba-intel ! This should cover cases like multiple SRC instances on different cores using the same configuration, so they'll re-use the SRAM copy of the parameters (@singalsu will correct me if I'm mixing things up). So, @kv2019i, yes, this looks correct, and no, I don't think it's a part of a systemic oversight - this is a very specific fast-get aspect - sharing copies of data between instances. And fast-get context (struct sof_fast_get_entry instances) should be kept synchronised between cores too, but those are already allocated as uncached.

entry->dram_ptr = dram_ptr;
entry->refcount = 1;
out:
Expand Down
Loading