Re: [PATCH] sched_ext: allow scx_bpf_task_cgroup() in ops.dispatch()

[Tejun Heo]

Hello,

On Wed, Sep 17, 2025 at 11:12:18AM +0900, Changwoo Min wrote:
> > I'm not sure this is safe tho. ops.dispatch() can release the rq lock it's
> > holding to migrate tasks across rq's, which means that other operations can
> > nest inside - ie. there can be an irq which triggers ops.enqueue() while
> > ops.dispatch() is in progress. That can in turn overwrite
> > current->scx.kf_tasks[].
> 
> I thought that ops.dispatch() always holds an rq lock since there
> is a lockdep_assert_rq_held(rq) check at the beginning of
> balance_one(), which invokes the BPF scheduler's dispatch.
> I guess I am missing an edge case?

ops.dispatch() is always called and returns with rq locked; however, it
sometimes needs to migrate tasks across rq boundaries and thus can
temporarily release the rq lock it was called with. Please take a look at
dispatch_to_local_dsq() which is called from balance_one() ->
flush_dispatch_buf() -> finish_dispatch().

> > I wonder whether a better approach would be tracking cgroup membership from
> > BPF side. ops.init_task() tells you the initial cgroup it's joining and if
> 
> Currently, it is also not allowed to call scx_bpf_task_cgroup()
> at ops.init_task() because the rq lock is not held at
> ops.init_task(). The earliest possible moment to get a task's
> cgroup ID is ops.enable().

ops.init_task() is called with scx_init_task_args, which contains .cgroup
which points to the CPU controller cgroup the task belongs to.

Thanks.

-- 
tejun