[PATCH] sched_ext: Use SCX_CALL_OP_TASK in task_tick_scx

[PATCH] sched_ext: Use SCX_CALL_OP_TASK in task_tick_scx

[Chuyi Zhou]

Now when we use scx_bpf_task_cgroup() in ops.tick() to get the cgroup of
the current task, the following error will occur:

scx_foo[3795244] triggered exit kind 1024:
  runtime error (called on a task not being operated on)

The reason is that we are using SCX_CALL_OP() instead of SCX_CALL_OP_TASK()
when calling ops.tick(), which triggers the error during the subsequent
scx_kf_allowed_on_arg_tasks() check.

SCX_CALL_OP_TASK() was first introduced in commit 36454023f50b ("sched_ext:
Track tasks that are subjects of the in-flight SCX operation") to ensure
task's rq lock is held when accessing task's sched_group. Since ops.tick()
is marked as SCX_KF_TERMINAL and task_tick_scx() is protected by the rq
lock, we can use SCX_CALL_OP_TASK() to avoid the above issue. Similarly,
the same changes should be made for ops.disable() and ops.exit_task(), as
they are also protected by task_rq_lock() and it's safe to access the
task's task_group.

Fixes: 36454023f50b ("sched_ext: Track tasks that are subjects of the in-flight SCX operation")
Signed-off-by: Chuyi Zhou <zhouchuyi@bytedance.com>
---
 kernel/sched/ext.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
index 54edd0e2132a..5a81d9a1e31f 100644
--- a/kernel/sched/ext.c
+++ b/kernel/sched/ext.c
@@ -3899,7 +3899,7 @@ static void task_tick_scx(struct rq *rq, struct task_struct *curr, int queued)
 		curr->scx.slice = 0;
 		touch_core_sched(rq, curr);
 	} else if (SCX_HAS_OP(tick)) {
-		SCX_CALL_OP(SCX_KF_REST, tick, curr);
+		SCX_CALL_OP_TASK(SCX_KF_REST, tick, curr);
 	}
 
 	if (!curr->scx.slice)
@@ -4046,7 +4046,7 @@ static void scx_ops_disable_task(struct task_struct *p)
 	WARN_ON_ONCE(scx_get_task_state(p) != SCX_TASK_ENABLED);
 
 	if (SCX_HAS_OP(disable))
-		SCX_CALL_OP(SCX_KF_REST, disable, p);
+		SCX_CALL_OP_TASK(SCX_KF_REST, disable, p);
 	scx_set_task_state(p, SCX_TASK_READY);
 }
 
@@ -4075,7 +4075,7 @@ static void scx_ops_exit_task(struct task_struct *p)
 	}
 
 	if (SCX_HAS_OP(exit_task))
-		SCX_CALL_OP(SCX_KF_REST, exit_task, p, &args);
+		SCX_CALL_OP_TASK(SCX_KF_REST, exit_task, p, &args);
 	scx_set_task_state(p, SCX_TASK_NONE);
 }
 
-- 
2.20.1

Re: [PATCH] sched_ext: Use SCX_CALL_OP_TASK in task_tick_scx

[Tejun Heo]

On Wed, Feb 12, 2025 at 09:09:35PM +0800, Chuyi Zhou wrote:
> Now when we use scx_bpf_task_cgroup() in ops.tick() to get the cgroup of
> the current task, the following error will occur:
> 
> scx_foo[3795244] triggered exit kind 1024:
>   runtime error (called on a task not being operated on)
> 
> The reason is that we are using SCX_CALL_OP() instead of SCX_CALL_OP_TASK()
> when calling ops.tick(), which triggers the error during the subsequent
> scx_kf_allowed_on_arg_tasks() check.
> 
> SCX_CALL_OP_TASK() was first introduced in commit 36454023f50b ("sched_ext:
> Track tasks that are subjects of the in-flight SCX operation") to ensure
> task's rq lock is held when accessing task's sched_group. Since ops.tick()
> is marked as SCX_KF_TERMINAL and task_tick_scx() is protected by the rq
> lock, we can use SCX_CALL_OP_TASK() to avoid the above issue. Similarly,
> the same changes should be made for ops.disable() and ops.exit_task(), as
> they are also protected by task_rq_lock() and it's safe to access the
> task's task_group.
> 
> Fixes: 36454023f50b ("sched_ext: Track tasks that are subjects of the in-flight SCX operation")
> Signed-off-by: Chuyi Zhou <zhouchuyi@bytedance.com>

Applied to sched_ext/for-6.14-fixes.

Thanks.

-- 
tejun