audio: module-adapter: make generic code compatible with user-space by kv2019i · Pull Request #10950 · thesofproject/sof

kv2019i · 2026-06-22T12:53:09Z

Series of patches to make generic module code safe to use from user-space.

kv2019i · 2026-06-22T12:53:20Z

For context, part of #10558

Copilot

Pull request overview

This PR aims to make generic module-adapter and data blob handling code safe/usable from user-space contexts by switching allocations to user-safe heap APIs and threading a heap choice through the data blob handler creation path.

Changes:

Extend comp_data_blob_handler_new_ext() with an optional struct k_heap *heap parameter and update the default wrapper.
Update generic module configuration/runtime allocations to use sof_heap_alloc()/sof_heap_free() (with sof_sys_user_heap_get()).
Pass the module allocator heap into comp_data_blob_handler_new_ext() from mod_data_blob_handler_new().

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
src/include/sof/audio/data_blob.h	Extends blob handler constructor API with an optional heap parameter and updates the inline wrapper.
src/audio/module_adapter/module/generic.c	Replaces config/runtime `rballoc`/`rfree` usage with `sof_heap_alloc`/`sof_heap_free` and passes allocator heap into blob handler creation.
src/audio/data_blob.c	Stores heap in the handler, allocates/frees handler via heap when provided, and adds “default heap” alloc/free helpers.

kv2019i · 2026-06-22T16:30:00Z

V2 pushed:

simplify the changes to comp_data_blob_handler_new_ext(), the 3rd commit can be dropped

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

lyakh · 2026-06-23T08:42:43Z

-	handler = rzalloc(SOF_MEM_FLAG_USER,
-			  sizeof(struct comp_data_blob_handler));
+	handler = sof_heap_alloc(heap, SOF_MEM_FLAG_USER | SOF_MEM_FLAG_COHERENT,
+				 sizeof(struct comp_data_blob_handler), 0);


could just use sof_sys_user_heap_get() directly as in other cases. But this one also adds COHERENT - that's on purpose, right? Maybe mention in the commit message

Ok, fixing both. Earlier version of the patch stored a heap instance, but no need for that. And COHERENT is a mistake, we should align flags. Will fix.

Solved in V3

lyakh · 2026-06-23T08:45:44Z

 		/* No space for config available yet, allocate now */
-		dst->data = rballoc(SOF_MEM_FLAG_USER, size);
+		dst->data = sof_heap_alloc(sof_sys_user_heap_get(),
+					   SOF_MEM_FLAG_USER, size, 0);


so, we're releasing some of VMH memory and using the standard heap here. Have you checked how big these allocations are typically and how many we switch? Do we need to reallocate some memory from VMH to the userspace heap?

Hmm, right. I don't think we should touch the virtual/direct heap mix in the same PRs as we add support for user-space LL use. And yeah, that's what I'm doing here and some of earlier rballoc(). I could use SOF_MEM_FLAG_LARGE_BUFFER to mark places where rballoc() was used, but that is hardcoded to kernel in current zephyr/alloc.c, so won't work either. But alas, some cleaner solution is needed. Sizing the VMH split is a much more complicated problem and I don't want to tackle that in these PRs...

New attempt in V3 to preserve current behaviour (and vmh split) in kernel only builds.

kv2019i

Inline responses... this will need more work.

kv2019i · 2026-06-23T12:50:06Z

-	handler = rzalloc(SOF_MEM_FLAG_USER,
-			  sizeof(struct comp_data_blob_handler));
+	handler = sof_heap_alloc(heap, SOF_MEM_FLAG_USER | SOF_MEM_FLAG_COHERENT,
+				 sizeof(struct comp_data_blob_handler), 0);


Ok, fixing both. Earlier version of the patch stored a heap instance, but no need for that. And COHERENT is a mistake, we should align flags. Will fix.

kv2019i · 2026-06-23T13:20:18Z

 		/* No space for config available yet, allocate now */
-		dst->data = rballoc(SOF_MEM_FLAG_USER, size);
+		dst->data = sof_heap_alloc(sof_sys_user_heap_get(),
+					   SOF_MEM_FLAG_USER, size, 0);


Hmm, right. I don't think we should touch the virtual/direct heap mix in the same PRs as we add support for user-space LL use. And yeah, that's what I'm doing here and some of earlier rballoc(). I could use SOF_MEM_FLAG_LARGE_BUFFER to mark places where rballoc() was used, but that is hardcoded to kernel in current zephyr/alloc.c, so won't work either. But alas, some cleaner solution is needed. Sizing the VMH split is a much more complicated problem and I don't want to tackle that in these PRs...

Modify the special handling of SOF_MEM_FLAG_USER_SHARED_BUFFER and SOF_MEM_FLAG_LARGE_BUFFER in z_impl_sof_heap_alloc(). First make the shared user heap special handling conditional on CONFIG_SOF_USERSPACE_USE_SHARED_HEAP. This flag is a special case as it is not a hint to the allocator but rather an explicit selector for a specific heap (similar to SOF_MEM_FLAG_L3). If defined in build, and the flag is passed to sof_heap_alloc(), the heap argument is ignored, and instead the shared user heap instance is always used. No functional change to current code. Unlike the shared heap flag, SOF_MEM_FLAG_LARGE_BUFFER is a more traditional flag, which serves as a hint to the allocator. Modify the implementation to ignore this flag if the caller has passed a non-NULL heap. Assumption here is that the heap user has passed is more suitable for large buffers than use of default rballoc_align(), so the hint can be ignored. This is especially important for cases where e.g. the caller is allocating memory to a different memory domain and using default rballoc_align() would result in access errors. If no heap is passed, the existing logic to use rballoc_align() is used. Functionality is modified only for cases where a custom heap is passed to alloc. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

Use user-space friendy sof_heap_alloc() for dynamic allocations in data_blob handler. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

Replace direct rballoc() and rfree() calls with sof_heap_alloc() and sof_heap_free(), and use sof_sys_user_heap_get() as the heap. This makes the code ready to be used in user-space, including module prepare and free stages. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

kv2019i · 2026-06-23T16:48:34Z

V3 pushed:

modified zephyr/lib/alloc.h to allow passing FLAG_LARGE_BUFFER to sof_heap_alloc() (allows to replace rballoc() with sof_heap_alloc() and preserve current semantics and behaviour in kernel-only builds with virtual heap)
addressing other code review feedback
marking again ready for review

Copilot AI review requested due to automatic review settings June 22, 2026 12:53

kv2019i requested review from dbaluta, lbetlej, lgirdwood, mmaka1 and plbossart as code owners June 22, 2026 12:53

Copilot started reviewing on behalf of kv2019i June 22, 2026 12:54 View session

Copilot AI reviewed Jun 22, 2026

View reviewed changes

Comment thread src/audio/data_blob.c Outdated

Comment thread src/include/sof/audio/data_blob.h Outdated

kv2019i force-pushed the 202606-module-adapt-userspace branch from 82045ae to dfc1660 Compare June 22, 2026 16:29

kv2019i requested a review from Copilot June 22, 2026 16:39

Copilot started reviewing on behalf of kv2019i June 22, 2026 16:40 View session

Copilot AI reviewed Jun 22, 2026

View reviewed changes

lyakh reviewed Jun 23, 2026

View reviewed changes

kv2019i commented Jun 23, 2026

View reviewed changes

kv2019i marked this pull request as draft June 23, 2026 13:20

kv2019i added 3 commits June 23, 2026 19:46

audio: module_adapter: make data_blob compatible with user-space

38b7bff

Use user-space friendy sof_heap_alloc() for dynamic allocations in data_blob handler. Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com>

kv2019i force-pushed the 202606-module-adapt-userspace branch from dfc1660 to 5431f77 Compare June 23, 2026 16:46

kv2019i marked this pull request as ready for review June 23, 2026 16:48

kv2019i requested review from abonislawski, dabekjakub and iuliana-prodan as code owners June 23, 2026 16:48

kv2019i requested review from serhiy-katsyuba-intel, softwarecki, tmleman and wjablon1 June 23, 2026 16:49

Conversation

kv2019i commented Jun 22, 2026

Uh oh!

kv2019i commented Jun 22, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

kv2019i commented Jun 22, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kv2019i left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kv2019i commented Jun 23, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants