linux-kernel - Re: [PATCH v2 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aQIuvlNSUAEGISl6@slm.duckdns.org>
Date: Wed, 29 Oct 2025 05:11:58 -1000
From: Tejun Heo <tj@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
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, Wen-Fang Liu <liuwenfang@...or.com>
Subject: Re: [PATCH v2 3/3] sched_ext: Allow scx_bpf_reenqueue_local() to be
 called from anywhere

Hello,

On Wed, Oct 29, 2025 at 11:45:46AM +0100, Peter Zijlstra wrote:
> On Mon, Oct 27, 2025 at 08:19:40AM -1000, Tejun Heo wrote:
> > The ops.cpu_acquire/release() callbacks are broken - they miss events under
> > multiple conditions and can't be fixed without adding global sched core hooks
> > that sched maintainers don't want.
> 
> I think I'll object to that statement just a wee bit. I think we can
> make it work -- just not with the things proposed earlier.

Sure, I'll massage it a bit before committing.

> Anyway, if you want to reduce the sched_ext interface and remove
> cpu_acquire/release entirely, this is fine too.
> 
> I might still do that wakeup_preempt() change if I can merge / replace
> the queue_mask RETRY_TASK logic -- I have vague memories the RT people
> also wanted something like this a while ago and it isn't that big of a
> change.

Yeah, being able to create some kind of interlocking from ttwu to pick_task
is something generally useful, I think, even if I don't use it right now.

> 6.23 is a long time, can't we throw this out quicker? This thing wasn't
> supposed to be an ABI after all. A 1 release cycle seems fine to me ;-)

We've been discussing about compat policy lately and I think what we landed
on was maintaining compatibility, when reasonably possible, over one LTS
release + a couple non-LTS releases, which comes out to ~1.5 to 2 years.
That seems to give most people enough sliding room while not choking us with
too much compat overhead. This is a bit more work but it is actually
surprisingly not that painful with all the BPF compat features, and seems to
hit a reasonable balance.

Thanks.

-- 
tejun