Skip to content

schedule: ll: dynamically allocate the semaphore - #11069

Open
lyakh wants to merge 1 commit into
thesofproject:mainfrom
lyakh:sem
Open

schedule: ll: dynamically allocate the semaphore#11069
lyakh wants to merge 1 commit into
thesofproject:mainfrom
lyakh:sem

Conversation

@lyakh

@lyakh lyakh commented Aug 6, 2026

Copy link
Copy Markdown
Collaborator

The LL scheduler semaphore is used by the userspace, so it has to be allocated dynamically. On the other hand dynamic object freeing from the userspace is unsupported by design. To securely free the semaphore object we add two syscalls that guarantee, that object freeing cannot be abused.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Pull request overview

This PR updates the Zephyr LL scheduler task teardown path to use a dynamically allocated k_sem (needed for userspace access), and introduces new syscall entry points to allocate/free that semaphore in a controlled way.

Changes:

  • Switch LL task private data from an embedded struct k_sem to a dynamically allocated struct k_sem *.
  • Add semaphore alloc/free syscall implementations and wire them into task init/free.
  • Register ll_schedule_domain.h for Zephyr syscall header generation.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File Description
zephyr/CMakeLists.txt Adds ll_schedule_domain.h to the set of headers used for syscall generation.
src/schedule/zephyr_ll.c Implements dynamic semaphore lifecycle, adds alloc/free syscalls, updates task init/free and access grants.
src/include/sof/schedule/ll_schedule_domain.h Exposes new syscall prototypes (or z_impl_ fallbacks) for LL task semaphore alloc/free.
Suppressed comments (3)

src/schedule/zephyr_ll.c:463

  • z_impl_zephyr_ll_task_sem_alloc() doesn’t validate task->priv_data and doesn’t guard against re-allocation (which can leak semaphores / list nodes). It also appends to the global list without locking.
int z_impl_zephyr_ll_task_sem_alloc(struct task *task)
{
	struct zephyr_ll_pdata *pdata = task->priv_data;
	struct zephyr_ll_task_sem *ts = rmalloc(SOF_MEM_FLAG_COHERENT, sizeof(*ts));

src/schedule/zephyr_ll.c:488

  • z_impl_zephyr_ll_task_sem_free() can be called from userspace at any time and currently frees the semaphore as long as it finds a matching entry. This can lead to use-after-free (e.g., zephyr_ll_task_free()/zephyr_ll_task_done() will later k_sem_take/give the freed semaphore). At minimum, gate freeing to the task-free path (e.g., require pdata->freeing) and serialize access to the global list.
	struct zephyr_ll_pdata *pdata = task->priv_data;
	struct list_item *list;
	struct zephyr_ll_task_sem *ts;
	bool found = false;

src/schedule/zephyr_ll.c:600

  • The return value of zephyr_ll_task_sem_free(task) is ignored. If freeing fails (e.g., due to an unexpected state), the code continues and frees pdata, potentially leaking the semaphore object / list node or leaving a dangling pdata->sem behind.
	zephyr_ll_task_sem_free(task);

Comment thread src/schedule/zephyr_ll.c Outdated
@kv2019i

kv2019i commented Aug 6, 2026

Copy link
Copy Markdown
Collaborator

Tested this today on device with LL-usespace build and seems to work fine.

@jsarha jsarha left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

LGTM

The LL scheduler semaphore is used by the userspace, so it has to be
allocated dynamically. On the other hand dynamic object freeing from
the userspace is unsupported by design. To securely free the
semaphore object we add two syscalls that guarantee, that object
freeing cannot be abused.

Signed-off-by: Guennadi Liakhovetski <guennadi.liakhovetski@linux.intel.com>
@lyakh

lyakh commented Aug 7, 2026

Copy link
Copy Markdown
Collaborator Author

dynamic objects aren't available without CONFIG_USERSPACE, so, had to update

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants