Re: [PATCH sched_ext/for-7.3-fixes] sched_ext: Pass the initial cmask to cid-form ops.enable()

[Tejun Heo <tj@kernel.org>]

Hello,

On Fri, Sep 18, 2026 at 11:39:24PM +0200, Andrea Righi wrote:
> Can we deliver the initial ops.set_cmask() before ops.set_weight()? Otherwise
> set_weight() can observe an empty or stale saved mask during the initial enable.
> This can matter if ops.set_weight() derives per-domain state from both the
> task's weight and its allowed cids.

Yeah, makes sense. Moved ahead of set_weight() in v3.

> Does this break existing cid-form scheduler that implements ops.enable()?
> If an existent scheduler moves the new prototype, does it load both with old and
> new kernels? In theory if the new args isn't used, LLVM should eliminate it, so
> existent BPF schedulers just need to use the new prototype and should be fine,
> but I haven't tested it.

The cid form is still considered unreleased, so compat isn't a concern there
yet and breaking an existing enable() is fine at this point. FWIW, I did test
it: a two-argument enable() that doesn't touch @args never reads the second
ctx slot and loads on the old kernel, one that reads it is rejected there
("func 'enable' doesn't have 3-th argument"), and an old one-argument
enable() loads fine on the new kernel.

> Can we also add a small selftest comparing the mask received by enable() with
> the immediately following set_cmask()? That would cover arena-pointer rebasing,
> mask contents, and callback ordering.

Added in v3.

Thanks.

--
tejun