Re: [PATCH] sched_ext: Reject NMI calls to lock-taking kfuncs

[Andrea Righi <arighi@nvidia.com>]

On Tue, Sep 01, 2026 at 10:13:27AM -1000, Tejun Heo wrote:
> Hello,
> 
> On Tue, Sep 01, 2026 at 09:51:37PM +0200, Andrea Righi wrote:
> > AFAICS, the lock-taking and state-changing kfuncs do not have a meaningful use
> > from BPF_PROG_TYPE_TRACING. We could move them out of scx_kfunc_ids_any into a
> > separate set registered only for BPF_PROG_TYPE_STRUCT_OPS. The read-only kfuncs
> > could remain available to tracing programs.
> > 
> > This should include:
> >  - scx_bpf_kick_cpu() / scx_bpf_kick_cid()
> >  - scx_bpf_destroy_dsq()
> >  - scx_bpf_dsq_reenq() / scx_bpf_reenqueue_local___v2()
> >  - bpf_iter_scx_dsq_{new,next,destroy}()
> >  - scx_bpf_cpuperf_set() / scx_bpf_cidperf_set()
> >  - scx_bpf_sub_grant() / scx_bpf_sub_revoke()
> >  (... maybe others that I'm missing ...)
> 
> Hmm... but it *is* useful to be able to e.g. kick a CPU or trigger reenq
> from a trace event, no?

Kicking a CPU, yes - scx_pair is actually using that.

I'm less convinced about the reenq case. We used to have the famous reenq from
sched_switch use case, but now that we have ENQ_IMMED and deadline server, are
there other concrete use cases for it?

Maybe we should decide tracing visibility per kfunc rather than exposing every
"any" kfunc and adding the runtime check to all of them. But this can be
revised/improved later. In the meantime this seems to fix a real issue and the
approach looks correct, so:

Acked-by: Andrea Righi <arighi@nvidia.com>

Thanks,
-Andrea