linux-kernel - Re: [PATCH v3 3/3] sched_ext: Allow scx_bpf_reenqueue

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: <aS9wuY2zu78rSc3G@slm.duckdns.org>
Date: Tue, 2 Dec 2025 13:05:29 -1000
From: Tejun Heo <tj@...nel.org>
To: Kuba Piecuch <jpiecuch@...gle.com>
Cc: David Vernet <void@...ifault.com>,
	Andrea Righi <andrea.righi@...ux.dev>,
	Changwoo Min <changwoo@...lia.com>, linux-kernel@...r.kernel.org,
	sched-ext@...ts.linux.dev, Peter Zijlstra <peterz@...radead.org>,
	Wen-Fang Liu <liuwenfang@...or.com>
Subject: Re: [PATCH v3 3/3] sched_ext: Allow scx_bpf_reenqueue_local() to be
 called from anywhere

Hello,

Sorry about the late response.

On Thu, Nov 27, 2025 at 10:39:35AM +0000, Kuba Piecuch wrote:
> On Wed Oct 29, 2025 at 3:49 PM UTC, Tejun Heo wrote:
> > Schedulers can now use standard BPF mechanisms like the sched_switch tracepoint
> > to detect and handle CPU preemption.
> 
> Correct me if I'm wrong, but I think using the sched_switch tracepoint still
> leaves us with no preemption notification in the following scenario:
> 
> 1. An RT task is running on the CPU and blocks.
> 
> 2. pick_task_scx() briefly drops the rq lock in balance_one() and the RT task
>    is woken up.
> 
> 3. SCX sees the enqueue and returns RETRY_TASK from pick_task_scx().
> 
> 4. The RT task is picked.
> 
> 5. Since prev == next, we don't enter the is_switch branch in __schedule()
>    and the sched_switch tracepoint isn't reached.

You're right.

> The BPF scheduler could hook into trace_sched_exit_tp() to work around this,
> but that tracepoint seems to be for testing and debugging purposes only.

Yes, that looks useable for now. Maybe we can add another hooking pointer
after the proposed core change from sched_ext side. Will think more about
that.

Thanks.

-- 
tejun