linux-kernel - Re: [PATCH v2 sched_ext/for-6.19] sched_ext: Use ___v2 suffix for new kfuncs and fix scx build errors

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aPk-S_E82BD1YfSM@slm.duckdns.org>
Date: Wed, 22 Oct 2025 10:27:55 -1000
From: Tejun Heo <tj@...nel.org>
To: Andrea Righi <arighi@...dia.com>
Cc: David Vernet <void@...ifault.com>, Changwoo Min <changwoo@...lia.com>,
	Emil Tsalapatis <emil@...alapatis.com>, sched-ext@...ts.linux.dev,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 sched_ext/for-6.19] sched_ext: Use ___v2 suffix for
 new kfuncs and fix scx build errors

Hello,

On Wed, Oct 22, 2025 at 09:38:14PM +0200, Andrea Righi wrote:
...
> Ahh ok, so user-space schedulers will always continue to pass all the
> arguments "normally" and we just assemble the args struct via an inline
> helper.
> 
> So, IIUC, using an _argpack suffix or something similar (instead of ___v2)
> should be a reasonable solution, right?

Yeah, something with less than three underscores as that has a different
meaning (ignore when matching).

> > Here, there is no noticeable feature difference before and after for
> > existing schedulers, so I don't think it's necessary to introduce __COMPAT
> > prefix.
> 
> The problem is that some schedulers (i.e., scx_bpfland, scx_cosmos) are
> explicitly checking bpf_ksym_exists(scx_bpf_select_cpu_and). If
> scx_bpf_select_cpu_and() becomes a static inline, we break the build and we
> also break binary compatibility. Hence the __COMPAT for the inline
> helpers...

Hmm... binary compatibility shouldn't break as the original
scx_bpf_select_cpu_and() is still there, right? Build breaks because now the
symbol is an inline one, but the solution there, I think, is either
providing a __COMPAT macro which helps testing the availability of
scx_bpf_select_cpu_and() or just making them test the ___compat symbol,
right? ie. kernel API changes aren't required to guarantee source level
backward compatibility (like how we did the dsq_insert renames) as long as
it provides a way to maintain both forward and backward binary
compatibility.

Thanks.

-- 
tejun