Hello, On Thu, Feb 27, 2025 at 09:23:20PM +0000, Juntong Deng wrote: > > > + if (prog->type == BPF_PROG_TYPE_STRUCT_OPS && > > > + prog->aux->st_ops != &bpf_sched_ext_ops) > > > + return 0; > > > > Why can't other struct_ops progs call scx_kfunc_ids_unlocked kfuncs? > > > > Return 0 means allowed. So kfuncs in scx_kfunc_ids_unlocked can be > called by other struct_ops programs. Hmm... would that mean a non-sched_ext bpf prog would be able to call e.g. scx_bpf_dsq_insert()? > > > + /* prog->type == BPF_PROG_TYPE_STRUCT_OPS && prog->aux->st_ops == &bpf_sched_ext_ops*/ > > > + > > > + moff = prog->aux->attach_st_ops_member_off; > > > + flags = scx_ops_context_flags[SCX_MOFF_IDX(moff)]; > > > + > > > + if ((flags & SCX_OPS_KF_UNLOCKED) && > > > + btf_id_set8_contains(&scx_kfunc_ids_unlocked, kfunc_id)) > > > + return 0; > > > > Wouldn't this disallow e.g. ops.dispatch() from calling scx_dsq_move()? > > > > No, because > > > > [SCX_OP_IDX(dispatch)] = SCX_OPS_KF_DISPATCH | SCX_OPS_KF_ENQUEUE, > > Therefore, kfuncs (scx_bpf_dsq_move_*) in scx_kfunc_ids_dispatch can be > called in the dispatch context. I see, scx_dsq_move_*() are in both groups, so it should be fine. I'm not fully sure the groupings are the actually implemented filtering are in sync. They are intended to be but the grouping didn't really matter in the previous implementation. So, they need to be carefully audited. > > Have you tested that the before and after behaviors match? > > I tested the programs in tools/testing/selftests/sched_ext and > tools/sched_ext and all worked fine. > > If there are other cases that are not covered, we may need to add new > test cases. Right, the coverage there isn't perfect. Testing all conditions would be too much but it'd be nice to have a test case which at least confirms that all allowed cases verify successfully. Thanks. -- tejun
