[PATCH] sched_ext: Fix scx_bpf_dsq_move_to_local___v2() to handle SCX_DSQ_GLOBAL

[PATCH] sched_ext: Fix scx_bpf_dsq_move_to_local___v2() to handle SCX_DSQ_GLOBAL

[Cheng-Yang Chou]

scx_bpf_dsq_move_to_local___v2() called find_user_dsq() for all dsq_id
values, but find_user_dsq() only searches the rhashtable of user-created
DSQs. SCX_DSQ_GLOBAL is a builtin DSQ stored in the per-node pnode and
not in the rhashtable, so passing SCX_DSQ_GLOBAL caused find_user_dsq()
to return NULL, triggering scx_error() and aborting the scheduler.

Add an explicit check for SCX_DSQ_GLOBAL and use find_global_dsq() in
that case, matching the pattern used in find_dsq_for_dispatch().

Fixes: 860683763ebf ("sched_ext: Add enq_flags to scx_bpf_dsq_move_to_local()")
Signed-off-by: Cheng-Yang Chou <yphbchou0911@gmail.com>
---
 kernel/sched/ext.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
index 551bfb99157d..0d0780c77ffd 100644
--- a/kernel/sched/ext.c
+++ b/kernel/sched/ext.c
@@ -8249,7 +8249,10 @@ __bpf_kfunc bool scx_bpf_dsq_move_to_local___v2(u64 dsq_id, u64 enq_flags,
 
 	flush_dispatch_buf(sch, dspc->rq);
 
-	dsq = find_user_dsq(sch, dsq_id);
+	if (dsq_id == SCX_DSQ_GLOBAL)
+		dsq = find_global_dsq(sch, cpu_of(dspc->rq));
+	else
+		dsq = find_user_dsq(sch, dsq_id);
 	if (unlikely(!dsq)) {
 		scx_error(sch, "invalid DSQ ID 0x%016llx", dsq_id);
 		return false;
-- 
2.48.1

Re: [PATCH] sched_ext: Fix scx_bpf_dsq_move_to_local___v2() to handle SCX_DSQ_GLOBAL

[Tejun Heo]

On Thu, Mar 26, 2026 at 05:17:30PM +0800, Cheng-Yang Chou wrote:
> scx_bpf_dsq_move_to_local___v2() called find_user_dsq() for all dsq_id
> values, but find_user_dsq() only searches the rhashtable of user-created
> DSQs. SCX_DSQ_GLOBAL is a builtin DSQ stored in the per-node pnode and
> not in the rhashtable, so passing SCX_DSQ_GLOBAL caused find_user_dsq()
> to return NULL, triggering scx_error() and aborting the scheduler.
> 
> Add an explicit check for SCX_DSQ_GLOBAL and use find_global_dsq() in
> that case, matching the pattern used in find_dsq_for_dispatch().

This is intentional. Both global and local DSQs are terminal and don't
provide interface for direct control once tasks are queued.

Thanks.

-- 
tejun

Re: [PATCH] sched_ext: Fix scx_bpf_dsq_move_to_local___v2() to handle SCX_DSQ_GLOBAL

[Cheng-Yang Chou]

Hi Tejun,

On Thu, Mar 26, 2026 at 01:22:59AM -1000, Tejun Heo wrote:
> On Thu, Mar 26, 2026 at 05:17:30PM +0800, Cheng-Yang Chou wrote:
> > scx_bpf_dsq_move_to_local___v2() called find_user_dsq() for all dsq_id
> > values, but find_user_dsq() only searches the rhashtable of user-created
> > DSQs. SCX_DSQ_GLOBAL is a builtin DSQ stored in the per-node pnode and
> > not in the rhashtable, so passing SCX_DSQ_GLOBAL caused find_user_dsq()
> > to return NULL, triggering scx_error() and aborting the scheduler.
> > 
> > Add an explicit check for SCX_DSQ_GLOBAL and use find_global_dsq() in
> > that case, matching the pattern used in find_dsq_for_dispatch().
> 
> This is intentional. Both global and local DSQs are terminal and don't
> provide interface for direct control once tasks are queued.

Thanks for the explanation!

Since the error message only says "invalid DSQ ID" without distinguishing
between "DSQ not found" and "intentionally unsupported terminal DSQ",
would it be worth adding a comment to clarify the design intent?

Something like: 

 /**
  * Only user-created DSQs are valid sources. Global and local DSQs are
  * terminal DSQs. Once a task is queued there it is committed to that
  * CPU's scheduling path and not subject to kfunc-based manipulation.
  */
  dsq = find_user_dsq(sch, dsq_id);

Or alternatively, a note in the kdoc:

  * @dsq_id: DSQ to move task from. Must be a user-created DSQ.
  *          SCX_DSQ_GLOBAL and local DSQs are terminal DSQs and are
  *          not supported as sources.

I think this would help future contributors avoid the same confusion.
What do you think?

-- 
Thanks,
Cheng-Yang

Re: [PATCH] sched_ext: Fix scx_bpf_dsq_move_to_local___v2() to handle SCX_DSQ_GLOBAL

[Tejun Heo]

Hello,

On Thu, Mar 26, 2026 at 10:24:54PM +0800, Cheng-Yang Chou wrote:
> Since the error message only says "invalid DSQ ID" without distinguishing
> between "DSQ not found" and "intentionally unsupported terminal DSQ",
> would it be worth adding a comment to clarify the design intent?

Yeah, sure. Note that. Local (along with user DSQs) now support
reenqueueing. When a task gets in a local DSQ, it either gets picked up by
the CPU for execution, gets dequeued for e.g. property changes, or can be
reenqueued. However, the BPF sched can directly iterate local DSQs or move
tasks in them. Global DSQ is similar but dosen't support reenq, mostly
because it's difficult to define the scope as SCX_DSQ_GLOBAL maps to
multiple currently per-node DSQs. This may change in the future.

Thanks.

-- 
tejun

Re: [PATCH] sched_ext: Fix scx_bpf_dsq_move_to_local___v2() to handle SCX_DSQ_GLOBAL

[Tejun Heo]

On Thu, Mar 26, 2026 at 09:46:39AM -1000, Tejun Heo wrote:
> reenqueued. However, the BPF sched can directly iterate local DSQs or move
                                     ^
                                     can't 

> tasks in them. Global DSQ is similar but dosen't support reenq, mostly

-- 
tejun