linux-kernel - Re: [PATCH] sched_ext: allow scx_bpf_task

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <edd77a64-6f7b-45cd-b2e9-36b67a7ca44e@igalia.com>
Date: Sat, 20 Sep 2025 11:15:35 +0900
From: Changwoo Min <changwoo@...lia.com>
To: Tejun Heo <tj@...nel.org>
Cc: void@...ifault.com, arighi@...dia.com, kernel-dev@...lia.com,
 sched-ext@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched_ext: allow scx_bpf_task_cgroup() in ops.dispatch()

Hello,

Thanks for the clarification.

On 9/17/25 14:00, Tejun Heo wrote:
> 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().

You are right. I overlooked that path.

>>> 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.

Yeah, that's better than relying on ops.enable().

Regards,
Changwoo Min