[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Z64ki36mCAmT0ORF@slm.duckdns.org>
Date: Thu, 13 Feb 2025 06:57:47 -1000
From: Tejun Heo <tj@...nel.org>
To: Chuyi Zhou <zhouchuyi@...edance.com>
Cc: void@...ifault.com, arighi@...dia.com, changwoo@...lia.com,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched_ext: Use SCX_CALL_OP_TASK in task_tick_scx
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@...edance.com>
Applied to sched_ext/for-6.14-fixes.
Thanks.
--
tejun
Powered by blists - more mailing lists