Repository navigation
Conversation
|
Hi @LFRon. Thanks for your PR. 😃 |
|
Hi @LFRon. Thanks for your PR. I'm waiting for a deepin-community member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
1f9a677 to
3f0e2aa
Compare
There was a problem hiding this comment.
Sorry @LFRon, your pull request is larger than the review limit of 150,000 diff characters
491e6aa to
08bda32
Compare
process_ddsp_deferred_locals() executes deferred direct dispatches to the local DSQs of remote CPUs. It iterates the tasks on rq->scx.ddsp_deferred_locals list, removing and calling dispatch_to_local_dsq() on each. However, the list is protected by the rq lock that can be dropped by dispatch_to_local_dsq() temporarily, so the list can be modified during the iteration, which can lead to oopses and other failures. Fix it by popping from the head of the list instead of iterating the list. Signed-off-by: Tejun Heo <tj@kernel.org> Fixes: 5b26f7b ("sched_ext: Allow SCX_DSQ_LOCAL_ON for direct dispatches") Acked-by: David Vernet <void@manifault.com> (cherry picked from commit 72763ea) Signed-off-by: LFRon <ronforever@outlook.com>
… SCX_RQ_ONLINE scx_rq_online() currently only tests SCX_RQ_ONLINE. This isn't fully correct - e.g. consume_dispatch_q() uses task_run_on_remote_rq() which tests scx_rq_online() to see whether the current rq can run the task, and, if so, calls consume_remote_task() to migrate the task to @rq. While the test itself was done while locking @rq, @rq can be temporarily unlocked by consume_remote_task() and nothing prevents SCX_RQ_ONLINE from going offline before the migration takes place. To address the issue, add cpu_active() test to scx_rq_online(). There is a synchronize_rcu() between cpu_active() being cleared and the rq going offline, so if an on-going scheduling operation sees cpu_active(), the associated rq is guaranteed to not go offline until the scheduling operation is complete. Signed-off-by: Tejun Heo <tj@kernel.org> Fixes: 60c27fb ("sched_ext: Implement sched_ext_ops.cpu_online/offline()") Acked-by: David Vernet <void@manifault.com> (cherry picked from commit 991ef53) Signed-off-by: LFRon <ronforever@outlook.com>
sched_ext currently doesn't generate messages when the BPF scheduler is enabled and disabled unless there are errors. It is useful to have paper trail. Improve logging around enable/disable: - Generate info messages on enable and non-error disable. - Update error exit message formatting so that it's consistent with non-error message. Also, prefix ei->msg with the BPF scheduler's name to make it clear where the message is coming from. - Shorten scx_exit_reason() strings for SCX_EXIT_UNREG* for brevity and consistency. v2: Use pr_*() instead of KERN_* consistently. (David) Signed-off-by: Tejun Heo <tj@kernel.org> Suggested-by: Phil Auld <pauld@redhat.com> Reviewed-by: Phil Auld <pauld@redhat.com> Acked-by: David Vernet <void@manifault.com> (cherry picked from commit 344576f) Signed-off-by: LFRon <ronforever@outlook.com>
`__bpf_ops_sched_ext_ops` was missing the initialization of some struct attributes. With https://lore.kernel.org/all/20240722183049.2254692-4-martin.lau@linux.dev/ every single attributes need to be initialized programs (like scx_layered) will fail to load. 05:26:48 [INFO] libbpf: struct_ops layered: member cgroup_init not found in kernel, skipping it as it's set to zero 05:26:48 [INFO] libbpf: struct_ops layered: member cgroup_exit not found in kernel, skipping it as it's set to zero 05:26:48 [INFO] libbpf: struct_ops layered: member cgroup_prep_move not found in kernel, skipping it as it's set to zero 05:26:48 [INFO] libbpf: struct_ops layered: member cgroup_move not found in kernel, skipping it as it's set to zero 05:26:48 [INFO] libbpf: struct_ops layered: member cgroup_cancel_move not found in kernel, skipping it as it's set to zero 05:26:48 [INFO] libbpf: struct_ops layered: member cgroup_set_weight not found in kernel, skipping it as it's set to zero 05:26:48 [WARN] libbpf: prog 'layered_dump': BPF program load failed: unknown error (-524) 05:26:48 [WARN] libbpf: prog 'layered_dump': -- BEGIN PROG LOAD LOG -- attach to unsupported member dump of struct sched_ext_ops processed 0 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0 -- END PROG LOAD LOG -- 05:26:48 [WARN] libbpf: prog 'layered_dump': failed to load: -524 05:26:48 [WARN] libbpf: failed to load object 'bpf_bpf' 05:26:48 [WARN] libbpf: failed to load BPF skeleton 'bpf_bpf': -524 Error: Failed to load BPF program Signed-off-by: Manu Bretelle <chantr4@gmail.com> Signed-off-by: Tejun Heo <tj@kernel.org> (cherry picked from commit 33d031e) Signed-off-by: LFRon <ronforever@outlook.com>
consume_remote_task() and dispatch_to_local_dsq() use move_task_to_local_dsq() to migrate the task to the target CPU. Currently, move_task_to_local_dsq() expects the caller to lock both the source and destination rq's. While this may save a few lock operations while the rq's are not contended, under contention, the double locking can exacerbate the situation significantly (refer to the linked message below). Update the migration path so that double locking is not used. move_task_to_local_dsq() now expects the caller to be locking the source rq, drops it and then acquires the destination rq lock. Code is simpler this way and, on a 2-way NUMA machine w/ Xeon Gold 6138, 'hackbench 100 thread 5000` shows ~3% improvement with scx_simple. Signed-off-by: Tejun Heo <tj@kernel.org> Suggested-by: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20240806082716.GP37996@noisy.programming.kicks-ass.net Acked-by: David Vernet <void@manifault.com> (cherry picked from commit 8990929) Signed-off-by: LFRon <ronforever@outlook.com>
Since dequeue_task() allowed to fail, there is a compile error:
kernel/sched/ext.c:3630:19: error: initialization of ‘bool (*)(struct rq*, struct task_struct *, int)’ {aka ‘_Bool (*)(struct rq *, struct task_struct *, int)’} from incompatible pointer type ‘void (*)(struct rq*, struct task_struct *, int)’
3630 | .dequeue_task = dequeue_task_scx,
| ^~~~~~~~~~~~~~~~
Allow dequeue_task_scx to fail too.
Fixes: 863ccdb ("sched: Allow sched_class::dequeue_task() to fail")
Signed-off-by: Yipeng Zou <zouyipeng@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
(cherry picked from commit 9ad2861)
Signed-off-by: LFRon <ronforever@outlook.com>
ARRAY_ELEM_PTR() is an access macro used to help the BPF verifier not
confused by offseted memory acceeses by yiedling a valid pointer or NULL in
a way that's clear to the verifier. As such, the canonical usage involves
checking NULL return from the macro. Note that in many cases, the NULL
condition can never happen - they're there just to hint the verifier.
In a bpf_loop in scx_central.bpf.c::central_dispatch(), the NULL check was
incorrect in that there was another dereference of the pointer in addition
to the NULL checked access. This worked as the pointer can never be NULL and
the verifier could tell it would never be NULL in this case.
However, this still looks wrong and trips smatch:
./tools/sched_ext/scx_central.bpf.c:205 ____central_dispatch()
error: we previously assumed 'gimme' could be null (see line 201)
./tools/sched_ext/scx_central.bpf.c
195
196 if (!scx_bpf_dispatch_nr_slots())
197 break;
198
199 /* central's gimme is never set */
200 gimme = ARRAY_ELEM_PTR(cpu_gimme_task, cpu, nr_cpu_ids);
201 if (gimme && !*gimme)
^^^^^
If gimme is NULL
202 continue;
203
204 if (dispatch_to_cpu(cpu))
--> 205 *gimme = false;
Fix the NULL check so that there are no derefs if NULL. This doesn't change
actual behavior.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: http://lkml.kernel.org/r/<955e1c3c-ace2-4a1d-b246-15b8196038a3@stanley.mountain>
(cherry picked from commit 59cfdf3)
Signed-off-by: LFRon <ronforever@outlook.com>
The cfi stub for ops.tick was missing which will fail scheduler loading after pending BPF changes. Add it. Signed-off-by: Tejun Heo <tj@kernel.org> (cherry picked from commit bf934be) Signed-off-by: LFRon <ronforever@outlook.com>
…dsq() When deciding whether a task can be migrated to a CPU, dispatch_to_local_dsq() was open-coding p->cpus_allowed and scx_rq_online() tests instead of using task_can_run_on_remote_rq(). This had two problems. - It was missing is_migration_disabled() check and thus could try to migrate a task which shouldn't leading to assertion and scheduling failures. - It was testing p->cpus_ptr directly instead of using task_allowed_on_cpu() and thus failed to consider ISA compatibility. Update dispatch_to_local_dsq() to use task_can_run_on_remote_rq(): - Move scx_ops_error() triggering into task_can_run_on_remote_rq(). - When migration isn't allowed, fall back to the global DSQ instead of the source DSQ by returning DTL_INVALID. This is both simpler and an overall better behavior. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Peter Zijlstra <peterz@infradead.org> Acked-by: David Vernet <void@manifault.com> (cherry picked from commit 0366017) Signed-off-by: LFRon <ronforever@outlook.com>
…core_sched() Since 3cf78c5 ("sched_ext: Unpin and repin rq lock from balance_scx()"), sched_ext's balance path terminates rq_pin in the outermost function. This is simpler and in line with what other balance functions are doing but it loses control over rq->clock_update_flags which makes assert_clock_udpated() trigger if other CPUs pins the rq lock. The only place this matters is touch_core_sched() which uses the timestamp to order tasks from sibling rq's. Switch to sched_clock_cpu(). Later, it may be better to use per-core dispatch sequence number. v2: Use sched_clock_cpu() instead of ktime_get_ns() per David. Signed-off-by: Tejun Heo <tj@kernel.org> Fixes: 3cf78c5 ("sched_ext: Unpin and repin rq lock from balance_scx()") Acked-by: David Vernet <void@manifault.com> Cc: Peter Zijlstra <peterz@infradead.org> (cherry picked from commit 62607d0) Signed-off-by: LFRon <ronforever@outlook.com>
Turns out the core_sched bits forgot to use the set_next_task(.first=true) variant. Notably: pick_next_task() := pick_task() + set_next_task(.first = true) Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20240813224015.614146342@infradead.org (cherry picked from commit 7d2180d) Signed-off-by: LFRon <ronforever@outlook.com>
The rule is that: pick_next_task() := pick_task() + set_next_task(.first = true) Turns out, there's still a few things in pick_next_task() that are missing from that combination. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20240813224015.724111109@infradead.org (cherry picked from commit dae4320) Signed-off-by: LFRon <ronforever@outlook.com>
With the goal of pushing put_prev_task() after pick_task() / into pick_next_task(). Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20240813224015.943143811@infradead.org (cherry picked from commit 260598f) Signed-off-by: LFRon <ronforever@outlook.com>
The current rule is that: pick_next_task() := pick_task() + set_next_task(.first = true) And many classes implement it directly as such. Change things around to make pick_next_task() optional while also changing the definition to: pick_next_task(prev) := pick_task() + put_prev_task() + set_next_task(.first = true) The reason is that sched_ext would like to have a 'final' call that knows the next task. By placing put_prev_task() right next to set_next_task() (as it already is for sched_core) this becomes trivial. As a bonus, this is a nice cleanup on its own. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20240813224016.051225657@infradead.org (cherry picked from commit fd03c5b) Signed-off-by: LFRon <ronforever@outlook.com>
Ensure the last put_prev_task() and the first set_next_task() always go together. Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lore.kernel.org/r/20240813224016.158454756@infradead.org (cherry picked from commit 436f3ee) Signed-off-by: LFRon <ronforever@outlook.com>
Introduce two new BPF kfuncs, bpf_preempt_disable and bpf_preempt_enable. These kfuncs allow disabling preemption in BPF programs. Nesting is allowed, since the intended use cases includes building native BPF spin locks without kernel helper involvement. Apart from that, this can be used to per-CPU data structures for cases where programs (or userspace) may preempt one or the other. Currently, while per-CPU access is stable, whether it will be consistent is not guaranteed, as only migration is disabled for BPF programs. Global functions are disallowed from being called, but support for them will be added as a follow up not just preempt kfuncs, but rcu_read_lock kfuncs as well. Static subprog calls are permitted. Sleepable helpers and kfuncs are disallowed in non-preemptible regions. Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20240424031315.2757363-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> [ADAPT] NOTE: three context-only adaptations: - helpers.c: kfuncs placed after bpf_rcu_read_unlock and registered in common_btf_ids; upstream's bpf_throw/bpf_wq neighbors are 6.9 features absent from this base. - check_helper_call: in_sleepable(env) -> env->prog->sleepable (this base has no per-state in_sleepable field; matches the existing rcu block's form). - state copy/compare: active_preempt_lock taken; the in_sleepable field copy/compare is dropped (field absent). (cherry picked from commit fc7566a) Signed-off-by: LFRon <ronforever@outlook.com>
[ Upstream commit 46f7ed3 ] There are three situations when a program logically exits and transfers control to the kernel or another program: bpf_throw, BPF_EXIT, and tail calls. The former two check for any lingering locks and references, but tail calls currently do not. Expand the checks to check for spin locks, RCU read sections and preempt disabled sections. Spin locks are indirectly preventing tail calls as function calls are disallowed, but the checks for preemption and RCU are more relaxed, hence ensure tail calls are prevented in their presence. Fixes: 9bb00b2 ("bpf: Add kfunc bpf_rcu_read_lock/unlock()") Fixes: fc7566a ("bpf: Introduce bpf_preempt_[disable,enable] kfuncs") Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20241103225940.1408302-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> [ADAPT] NOTE: check_reference_leak() in this base takes no second argument (upstream's bool param arrives with a later refactor), so the call keeps the existing 1-arg form; the added checks are otherwise taken verbatim. (cherry picked from commit aa51be3) Signed-off-by: LFRon <ronforever@outlook.com>
Extract the part of check_helper_call() as a utility function allowing to query 'struct bpf_func_proto' for a specific helper function id. Acked-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20240722233844.1406874-2-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> [ADAPT] NOTE: the pre-image in this base differs only in older wording of the invalid/unknown-func branches; the added get_helper_proto() and its call site are taken verbatim, i.e. the post-image is identical to upstream. (cherry picked from commit 45cbc7a) Signed-off-by: LFRon <ronforever@outlook.com>
The verifier currently does not permit global subprog calls when a lock is held, preemption is disabled, or when IRQs are disabled. This is because we don't know whether the global subprog calls sleepable functions or not. In case of locks, there's an additional reason: functions called by the global subprog may hold additional locks etc. The verifier won't know while verifying the global subprog whether it was called in context where a spin lock is already held by the program. Perform summarization of the sleepable nature of a global subprog just like changes_pkt_data and then allow calls to global subprogs for non-sleepable ones from atomic context. While making this change, I noticed that RCU read sections had no protection against sleepable global subprog calls, include it in the checks and fix this while we're at it. Care needs to be taken to not allow global subprog calls when regular bpf_spin_lock is held. When resilient spin locks is held, we want to potentially have this check relaxed, but not for now. Also make sure extensions freplacing global functions cannot do so in case the target is non-sleepable, but the extension is. The other combination is ok. Tests are included in the next patch to handle all special conditions. Fixes: 9bb00b2 ("bpf: Add kfunc bpf_rcu_read_lock/unlock()") Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20250301151846.1552362-2-memxor@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> [ADAPT] NOTE: four context adaptations for this base: - check_func_call: plural active_locks/active_preempt_locks -> this base's active_lock.ptr/active_preempt_lock; the active_irq_id clause (IRQ-disabled kfuncs, 6.16) is not applicable; in_sleepable(env) -> env->prog->sleepable. - bpf_prog_aux/bpf_subprog_info fields inserted adjacent to the existing changes_pkt_data members; jit_subprogs line added without the 6.9 exception_cb/exception_boundary context. - everything else (mark_subprog_might_sleep, merge_callee_effects, visit_insn helper/kfunc marking, check_cfg, attach-target check) taken verbatim. (cherry picked from commit e2d8f56) Signed-off-by: LFRon <ronforever@outlook.com>
Verifier enforces that all iterator structs are named `bpf_iter_<name>` and that whenever iterator is passed to a kfunc it's passed as a valid PTR -> STRUCT chain (with potentially const modifiers in between). We'll need this check for upcoming changes, so instead of duplicating the logic, extract it into a helper function. Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20240808232230.2848712-2-andrii@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org> (cherry picked from commit 496ddd1) Signed-off-by: LFRon <ronforever@outlook.com>
There are potentially useful cases where a specific iterator type might
need to be passed into some kfunc. So, in addition to existing
bpf_iter_<type>_{new,next,destroy}() kfuncs, allow to pass iterator
pointer to any kfunc.
We employ "__iter" naming suffix for arguments that are meant to accept
iterators. We also enforce that they accept PTR -> STRUCT btf_iter_<type>
type chain and point to a valid initialized on-the-stack iterator state.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/r/20240808232230.2848712-3-andrii@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
[ADAPT] NOTE: this base already carries bdbf874's PTR_TO_STACK pre-check
(local 6724aea), kept as-is above the new btf_check_iter_arg() block; the
rest matches upstream's post-image.
(cherry picked from commit baebe9a)
Signed-off-by: LFRon <ronforever@outlook.com>
[ Upstream commit bd74e23 ] Andrii spotted that process_dynptr_func's rejection of incorrect argument register type will print an error string where argument numbers are not zero-indexed, unlike elsewhere in the verifier. Fix this by subtracting 1 from regno. The same scenario exists for iterator messages. Fix selftest error strings that match on the exact argument number while we're at it to ensure clean bisection. Suggested-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20241203002235.3776418-1-memxor@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> [ADAPT] NOTE: kernel-side only; the selftest portion of this commit is not picked (this project backports kernel-side only). The process_dynptr_func pointer-type-check message hunk is skipped because that check is absent from this base (it belongs to a different, un-ported commit); the other five arg-index fixes are taken verbatim. (cherry picked from commit fdaaf92) Signed-off-by: LFRon <ronforever@outlook.com>
[ Upstream commit e4414b0 ] kernel test robot reported verifier bug [1] where the helper func pointer could be NULL due to disabled config option. As Alexei suggested we could check on that in get_helper_proto directly. Marking tail_call helper func with BPF_PTR_POISON, because it is unused by design. [1] https://lore.kernel.org/oe-lkp/202507160818.68358831-lkp@intel.com Reported-by: kernel test robot <oliver.sang@intel.com> Reported-by: syzbot+a9ed3d9132939852d0df@syzkaller.appspotmail.com Suggested-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Paul Chaignon <paul.chaignon@gmail.com> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20250814200655.945632-1-jolsa@kernel.org Closes: https://lore.kernel.org/oe-lkp/202507160818.68358831-lkp@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 3d429cb1278e995e22995ef117fa96d223a67e93) Signed-off-by: LFRon <ronforever@outlook.com>
deepin inclusion category: kabi When DEEPIN_KABI_RESERVE=y, struct bpf_prog_aux, struct bpf_verifier_state and struct bpf_subprog_info are kabi whitelisted. The sched_ext backport series on this branch added upstream fields in the middle of these structs, which changes the struct layout and the genksyms checksum: - bpf_prog_aux: struct bpf_arena *arena, bool might_sleep - bpf_verifier_state: u32 may_goto_depth, u32 active_preempt_lock - bpf_subprog_info: u16 stack_extra, bool might_sleep: 1 The fields come from the bpf_arena, may_goto, preempt kfunc and sleepable global subprog summarization backports. They are verifier internal, no 3rd party driver uses them, and they are only accessed by name (no offset based access exists), so each struct's free DEEPIN_KABI_RESERVE() slots can be consumed with DEEPIN_KABI_USE() instead. This keeps the offsets of all previously existing members, the total size and the kABI checksum unchanged. Verified: kernel/sched/build_policy.o (includes ext.c) and kernel/bpf/verifier.o build cleanly both with and without CONFIG_DEEPIN_KABI_RESERVE=y. Signed-off-by: LFRon <ronforever@outlook.com>
In order to further simplify the code in adjust_scalar_min_max_vals all
the calls to mark_reg_unknown are replaced by __mark_reg_unknown.
static void mark_reg_unknown(struct bpf_verifier_env *env,
struct bpf_reg_state *regs, u32 regno)
{
if (WARN_ON(regno >= MAX_BPF_REG)) {
... mark all regs not init ...
return;
}
__mark_reg_unknown(env, regs + regno);
}
The 'regno >= MAX_BPF_REG' does not apply to
adjust_scalar_min_max_vals(), because it is only called from the
following stack:
- check_alu_op
- adjust_reg_min_max_vals
- adjust_scalar_min_max_vals
The check_alu_op() does check_reg_arg() which verifies that both src and
dst register numbers are within bounds.
Signed-off-by: Cupertino Miranda <cupertino.miranda@oracle.com>
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Cc: Yonghong Song <yonghong.song@linux.dev>
Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: David Faust <david.faust@oracle.com>
Cc: Jose Marchesi <jose.marchesi@oracle.com>
Cc: Elena Zannoni <elena.zannoni@oracle.com>
Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Link: https://lore.kernel.org/r/20240506141849.185293-2-cupertino.miranda@oracle.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
(cherry picked from commit d786957)
Signed-off-by: LFRon <ronforever@outlook.com>
Split range computation checks in its own function, isolating pessimitic range set for dst_reg and failing return to a single point. Signed-off-by: Cupertino Miranda <cupertino.miranda@oracle.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Cc: Yonghong Song <yonghong.song@linux.dev> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com> Cc: David Faust <david.faust@oracle.com> Cc: Jose Marchesi <jose.marchesi@oracle.com> Cc: Elena Zannoni <elena.zannoni@oracle.com> Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com> bpf/verifier: improve code after range computation recent changes. Link: https://lore.kernel.org/r/20240506141849.185293-3-cupertino.miranda@oracle.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> (cherry picked from commit 0922c78) Signed-off-by: LFRon <ronforever@outlook.com>
Range for XOR and OR operators would not be attempted unless src_reg would resolve to a single value, i.e. a known constant value. This condition is unnecessary, and the following XOR/OR operator handling could compute a possible better range. Acked-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Cupertino Miranda <cupertino.miranda@oracle.com Acked-by: Eduard Zingerman <eddyz87@gmail.com> Cc: Yonghong Song <yonghong.song@linux.dev> Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com> Cc: David Faust <david.faust@oracle.com> Cc: Jose Marchesi <jose.marchesi@oracle.com> Cc: Elena Zannoni <elena.zannoni@oracle.com> Cc: Andrii Nakryiko <andrii.nakryiko@gmail.com> Link: https://lore.kernel.org/r/20240506141849.185293-4-cupertino.miranda@oracle.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> (cherry picked from commit 138cc42) Signed-off-by: LFRon <ronforever@outlook.com>
Daniel Hodges reported a kernel verifier crash when playing with sched-ext.
Further investigation shows that the crash is due to invalid memory access
in stacksafe(). More specifically, it is the following code:
if (exact != NOT_EXACT &&
old->stack[spi].slot_type[i % BPF_REG_SIZE] !=
cur->stack[spi].slot_type[i % BPF_REG_SIZE])
return false;
The 'i' iterates old->allocated_stack.
If cur->allocated_stack < old->allocated_stack the out-of-bound
access will happen.
To fix the issue add 'i >= cur->allocated_stack' check such that if
the condition is true, stacksafe() should fail. Otherwise,
cur->stack[spi].slot_type[i % BPF_REG_SIZE] memory access is legal.
Fixes: 2793a8b ("bpf: exact states comparison for iterator convergence checks")
Cc: Eduard Zingerman <eddyz87@gmail.com>
Reported-by: Daniel Hodges <hodgesd@meta.com>
Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
Link: https://lore.kernel.org/r/20240812214847.213612-1-yonghong.song@linux.dev
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
(cherry picked from commit bed2eb9)
Signed-off-by: LFRon <ronforever@outlook.com>
Currently bpf_get_current_pid_tgid() is allowed in tracing, cgroup and sk_msg progs while bpf_get_ns_current_pid_tgid() is only allowed in tracing progs. We have an internal use case where for an application running in a container (with pid namespace), user wants to get the pid associated with the pid namespace in a cgroup bpf program. Currently, cgroup bpf progs already allow bpf_get_current_pid_tgid(). Let us allow bpf_get_ns_current_pid_tgid() as well. With auditing the code, bpf_get_current_pid_tgid() is also used by sk_msg prog. But there are no side effect to expose these two helpers to all prog types since they do not reveal any kernel specific data. The detailed discussion is in [1]. So with this patch, both bpf_get_current_pid_tgid() and bpf_get_ns_current_pid_tgid() are put in bpf_base_func_proto(), making them available to all program types. [1] https://lore.kernel.org/bpf/20240307232659.1115872-1-yonghong.song@linux.dev/ Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/bpf/20240315184854.2975190-1-yonghong.song@linux.dev (cherry picked from commit eb166e522c715f45f2623a1c694c100b106f3187) Signed-off-by: LFRon <ronforever@outlook.com>
Enable CONFIG_SCHED_CLASS_EXT=y for the deepin desktop kernel so that the sched_ext extensible scheduler class backported on this branch is built into the product kernel. All Kconfig dependencies are already satisfied: CONFIG_BPF_JIT=y CONFIG_DEBUG_INFO_BTF=y CONFIG_BPF_SYSCALL=y (Kconfig default y) CONFIG_CGROUP_SCHED=y (Kconfig default y) CONFIG_EXT_GROUP_SCHED is a hidden option (default y) and gets enabled automatically along with SCHED_CLASS_EXT. This is a local configuration commit, not an upstream cherry-pick; the sched_ext implementation itself comes from the upstream 6.12 commits on this branch (see backport-manifest.md). Verified by generating a fresh config from this defconfig: make O=<scratch> deepin_x86_desktop_defconfig grep CONFIG_SCHED_CLASS_EXT .config => CONFIG_SCHED_CLASS_EXT=y grep CONFIG_EXT_GROUP_SCHED .config => CONFIG_EXT_GROUP_SCHED=y Signed-off-by: LFRon <ronforever@outlook.com>
A poorly behaving BPF scheduler can live-lock the system by e.g. incessantly banging on the same DSQ on a large NUMA system to the point where switching to the bypass mode can take a long time. Turning on the bypass mode requires dequeueing and re-enqueueing currently runnable tasks, if the DSQs that they are on are live-locked, this can take tens of seconds cascading into other failures. This was observed on 2 x Intel Sapphire Rapids machines with 224 logical CPUs. Inject artifical delays while the bypass mode is switching to guarantee timely completion. While at it, move __scx_ops_bypass_lock into scx_ops_bypass() and rename it to bypass_lock. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Valentin Andrei <vandrei@meta.com> Reported-by: Patrick Lu <patlu@meta.com> (cherry picked from commit 62dcbab) Signed-off-by: LFRon <ronforever@outlook.com>
On 2 x Intel Sapphire Rapids machines with 224 logical CPUs, a poorly behaving BPF scheduler can live-lock the system by making multiple CPUs bang on the same DSQ to the point where soft-lockup detection triggers before SCX's own watchdog can take action. It also seems possible that the machine can be live-locked enough to prevent scx_ops_helper, which is an RT task, from running in a timely manner. Implement scx_softlockup() which is called when three quarters of soft-lockup threshold has passed. The function immediately enables the ops breather and triggers an ops error to initiate ejection of the BPF scheduler. The previous and this patch combined enable the kernel to reliably recover the system from live-lock conditions that can be triggered by a poorly behaving BPF scheduler on Intel dual socket systems. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Andrew Morton <akpm@linux-foundation.org> (cherry picked from commit e32c260) Signed-off-by: LFRon <ronforever@outlook.com>
…d context 4c30f5c ("sched_ext: Implement scx_bpf_dispatch[_vtime]_from_dsq()") added four kfuncs for dispatching while iterating. They are allowed from the dispatch and unlocked contexts but two of the kfuncs were only added in the dispatch section. Add missing declarations in the unlocked section. Signed-off-by: Tejun Heo <tj@kernel.org> Fixes: 4c30f5c ("sched_ext: Implement scx_bpf_dispatch[_vtime]_from_dsq()") (cherry picked from commit 72b85bf) Signed-off-by: LFRon <ronforever@outlook.com>
…time]() In sched_ext API, a repeatedly reported pain point is the overuse of the verb "dispatch" and confusion around "consume": - ops.dispatch() - scx_bpf_dispatch[_vtime]() - scx_bpf_consume() - scx_bpf_dispatch[_vtime]_from_dsq*() This overloading of the term is historical. Originally, there were only built-in DSQs and moving a task into a DSQ always dispatched it for execution. Using the verb "dispatch" for the kfuncs to move tasks into these DSQs made sense. Later, user DSQs were added and scx_bpf_dispatch[_vtime]() updated to be able to insert tasks into any DSQ. The only allowed DSQ to DSQ transfer was from a non-local DSQ to a local DSQ and this operation was named "consume". This was already confusing as a task could be dispatched to a user DSQ from ops.enqueue() and then the DSQ would have to be consumed in ops.dispatch(). Later addition of scx_bpf_dispatch_from_dsq*() made the confusion even worse as "dispatch" in this context meant moving a task to an arbitrary DSQ from a user DSQ. Clean up the API with the following renames: 1. scx_bpf_dispatch[_vtime]() -> scx_bpf_dsq_insert[_vtime]() 2. scx_bpf_consume() -> scx_bpf_dsq_move_to_local() 3. scx_bpf_dispatch[_vtime]_from_dsq*() -> scx_bpf_dsq_move[_vtime]*() This patch performs the first set of renames. Compatibility is maintained by: - The previous kfunc names are still provided by the kernel so that old binaries can run. Kernel generates a warning when the old names are used. - compat.bpf.h provides wrappers for the new names which automatically fall back to the old names when running on older kernels. They also trigger build error if old names are used for new builds. The compat features will be dropped after v6.15. v2: Documentation updates. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Changwoo Min <changwoo@igalia.com> Acked-by: Johannes Bechberger <me@mostlynerdless.de> Acked-by: Giovanni Gherdovich <ggherdovich@suse.com> Cc: Dan Schatzberg <dschatzberg@meta.com> Cc: Ming Yang <yougmark94@gmail.com> (cherry picked from commit cc26abb) Signed-off-by: LFRon <ronforever@outlook.com>
In sched_ext API, a repeatedly reported pain point is the overuse of the verb "dispatch" and confusion around "consume": - ops.dispatch() - scx_bpf_dispatch[_vtime]() - scx_bpf_consume() - scx_bpf_dispatch[_vtime]_from_dsq*() This overloading of the term is historical. Originally, there were only built-in DSQs and moving a task into a DSQ always dispatched it for execution. Using the verb "dispatch" for the kfuncs to move tasks into these DSQs made sense. Later, user DSQs were added and scx_bpf_dispatch[_vtime]() updated to be able to insert tasks into any DSQ. The only allowed DSQ to DSQ transfer was from a non-local DSQ to a local DSQ and this operation was named "consume". This was already confusing as a task could be dispatched to a user DSQ from ops.enqueue() and then the DSQ would have to be consumed in ops.dispatch(). Later addition of scx_bpf_dispatch_from_dsq*() made the confusion even worse as "dispatch" in this context meant moving a task to an arbitrary DSQ from a user DSQ. Clean up the API with the following renames: 1. scx_bpf_dispatch[_vtime]() -> scx_bpf_dsq_insert[_vtime]() 2. scx_bpf_consume() -> scx_bpf_dsq_move_to_local() 3. scx_bpf_dispatch[_vtime]_from_dsq*() -> scx_bpf_dsq_move[_vtime]*() This patch performs the second rename. Compatibility is maintained by: - The previous kfunc names are still provided by the kernel so that old binaries can run. Kernel generates a warning when the old names are used. - compat.bpf.h provides wrappers for the new names which automatically fall back to the old names when running on older kernels. They also trigger build error if old names are used for new builds. The compat features will be dropped after v6.15. v2: Comment and documentation updates. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Changwoo Min <changwoo@igalia.com> Acked-by: Johannes Bechberger <me@mostlynerdless.de> Acked-by: Giovanni Gherdovich <ggherdovich@suse.com> Cc: Dan Schatzberg <dschatzberg@meta.com> Cc: Ming Yang <yougmark94@gmail.com> (cherry picked from commit 5209c03) Signed-off-by: LFRon <ronforever@outlook.com>
…_move[_vtime]*() In sched_ext API, a repeatedly reported pain point is the overuse of the verb "dispatch" and confusion around "consume": - ops.dispatch() - scx_bpf_dispatch[_vtime]() - scx_bpf_consume() - scx_bpf_dispatch[_vtime]_from_dsq*() This overloading of the term is historical. Originally, there were only built-in DSQs and moving a task into a DSQ always dispatched it for execution. Using the verb "dispatch" for the kfuncs to move tasks into these DSQs made sense. Later, user DSQs were added and scx_bpf_dispatch[_vtime]() updated to be able to insert tasks into any DSQ. The only allowed DSQ to DSQ transfer was from a non-local DSQ to a local DSQ and this operation was named "consume". This was already confusing as a task could be dispatched to a user DSQ from ops.enqueue() and then the DSQ would have to be consumed in ops.dispatch(). Later addition of scx_bpf_dispatch_from_dsq*() made the confusion even worse as "dispatch" in this context meant moving a task to an arbitrary DSQ from a user DSQ. Clean up the API with the following renames: 1. scx_bpf_dispatch[_vtime]() -> scx_bpf_dsq_insert[_vtime]() 2. scx_bpf_consume() -> scx_bpf_dsq_move_to_local() 3. scx_bpf_dispatch[_vtime]_from_dsq*() -> scx_bpf_dsq_move[_vtime]*() This patch performs the third set of renames. Compatibility is maintained by: - The previous kfunc names are still provided by the kernel so that old binaries can run. Kernel generates a warning when the old names are used. - compat.bpf.h provides wrappers for the new names which automatically fall back to the old names when running on older kernels. They also trigger build error if old names are used for new builds. - scx_bpf_dispatch[_vtime]_from_dsq*() were already wrapped in __COMPAT macros as they were introduced during v6.12 cycle. Wrap new API in __COMPAT macros too and trigger build errors on both __COMPAT prefixed and naked usages of the old names. The compat features will be dropped after v6.15. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-by: Andrea Righi <arighi@nvidia.com> Acked-by: Changwoo Min <changwoo@igalia.com> Acked-by: Johannes Bechberger <me@mostlynerdless.de> Acked-by: Giovanni Gherdovich <ggherdovich@suse.com> Cc: Dan Schatzberg <dschatzberg@meta.com> Cc: Ming Yang <yougmark94@gmail.com> (cherry picked from commit 5cbb302) Signed-off-by: LFRon <ronforever@outlook.com>
Returns a high-performance monotonically non-decreasing clock for the current CPU. The clock returned is in nanoseconds. It provides the following properties: 1) High performance: Many BPF schedulers call bpf_ktime_get_ns() frequently to account for execution time and track tasks' runtime properties. Unfortunately, in some hardware platforms, bpf_ktime_get_ns() -- which eventually reads a hardware timestamp counter -- is neither performant nor scalable. scx_bpf_now() aims to provide a high-performance clock by using the rq clock in the scheduler core whenever possible. 2) High enough resolution for the BPF scheduler use cases: In most BPF scheduler use cases, the required clock resolution is lower than the most accurate hardware clock (e.g., rdtsc in x86). scx_bpf_now() basically uses the rq clock in the scheduler core whenever it is valid. It considers that the rq clock is valid from the time the rq clock is updated (update_rq_clock) until the rq is unlocked (rq_unpin_lock). 3) Monotonically non-decreasing clock for the same CPU: scx_bpf_now() guarantees the clock never goes backward when comparing them in the same CPU. On the other hand, when comparing clocks in different CPUs, there is no such guarantee -- the clock can go backward. It provides a monotonically *non-decreasing* clock so that it would provide the same clock values in two different scx_bpf_now() calls in the same CPU during the same period of when the rq clock is valid. An rq clock becomes valid when it is updated using update_rq_clock() and invalidated when the rq is unlocked using rq_unpin_lock(). Let's suppose the following timeline in the scheduler core: T1. rq_lock(rq) T2. update_rq_clock(rq) T3. a sched_ext BPF operation T4. rq_unlock(rq) T5. a sched_ext BPF operation T6. rq_lock(rq) T7. update_rq_clock(rq) For [T2, T4), we consider that rq clock is valid (SCX_RQ_CLK_VALID is set), so scx_bpf_now() calls during [T2, T4) (including T3) will return the rq clock updated at T2. For duration [T4, T7), when a BPF scheduler can still call scx_bpf_now() (T5), we consider the rq clock is invalid (SCX_RQ_CLK_VALID is unset at T4). So when calling scx_bpf_now() at T5, we will return a fresh clock value by calling sched_clock_cpu() internally. Also, to prevent getting outdated rq clocks from a previous scx scheduler, invalidate all the rq clocks when unloading a BPF scheduler. One example of calling scx_bpf_now(), when the rq clock is invalid (like T5), is in scx_central [1]. The scx_central scheduler uses a BPF timer for preemptive scheduling. In every msec, the timer callback checks if the currently running tasks exceed their timeslice. At the beginning of the BPF timer callback (central_timerfn in scx_central.bpf.c), scx_central gets the current time. When the BPF timer callback runs, the rq clock could be invalid, the same as T5. In this case, scx_bpf_now() returns a fresh clock value rather than returning the old one (T2). [1] https://github.com/sched-ext/scx/blob/main/scheds/c/scx_central.bpf.c Signed-off-by: Changwoo Min <changwoo@igalia.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org> (cherry picked from commit 3a9910b) Signed-off-by: LFRon <ronforever@outlook.com>
scx_bpf_now() is added to the header files so the BPF scheduler can use it. Signed-off-by: Changwoo Min <changwoo@igalia.com> Acked-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org> (cherry picked from commit 2e1ce39) Signed-off-by: LFRon <ronforever@outlook.com>
08bda32 to
71bc97f
Compare
There was a problem hiding this comment.
🟡 Changes recommended
It breaks the documented task_struct kABI and contains selftest and scheduler-tool bugs that can hide failures or corrupt memory.
5 open findings
Store sched_ext task state in task_struct_deepin for kABI stability · New Use CPU_ALLOC_SIZE consistently with dynamically allocated CPU masks · New Reset option parsing so restarted schedulers retain -f · New Honor exit requests and stop launching tests · New Write only formatted bytes and use the correct signed long format · New
What changed in this PR
Backports sched_ext and its BPF infrastructure, tooling, examples, and selftests to the 6.6 kernel tree.
Changes:
- Adds the sched_ext scheduling class and scheduler integration.
- Backports required BPF, struct_ops, arena, and sparse-vmalloc support.
- Adds sched_ext tools, documentation, example schedulers, and selftests.
| File | Description |
|---|---|
tools/testing/selftests/sched_ext/util.h |
Declares test utilities. |
tools/testing/selftests/sched_ext/util.c |
Implements file utilities. |
tools/testing/selftests/sched_ext/test_example.c |
Adds framework example test. |
tools/testing/selftests/sched_ext/select_cpu_vtime.c |
Adds vtime dispatch test. |
tools/testing/selftests/sched_ext/select_cpu_vtime.bpf.c |
Implements vtime test scheduler. |
tools/testing/selftests/sched_ext/select_cpu_dispatch.c |
Tests direct CPU dispatch. |
tools/testing/selftests/sched_ext/select_cpu_dispatch.bpf.c |
Implements dispatch test scheduler. |
tools/testing/selftests/sched_ext/select_cpu_dispatch_dbl_dsp.c |
Tests duplicate dispatch failure. |
tools/testing/selftests/sched_ext/select_cpu_dispatch_dbl_dsp.bpf.c |
Triggers duplicate dispatch. |
tools/testing/selftests/sched_ext/select_cpu_dispatch_bad_dsq.c |
Tests invalid DSQ handling. |
tools/testing/selftests/sched_ext/select_cpu_dispatch_bad_dsq.bpf.c |
Dispatches to invalid DSQ. |
tools/testing/selftests/sched_ext/select_cpu_dfl.c |
Tests default CPU selection. |
tools/testing/selftests/sched_ext/select_cpu_dfl.bpf.c |
Implements default-selection scheduler. |
tools/testing/selftests/sched_ext/select_cpu_dfl_nodispatch.c |
Tests no-dispatch selection mode. |
tools/testing/selftests/sched_ext/select_cpu_dfl_nodispatch.bpf.c |
Implements no-dispatch scheduler. |
tools/testing/selftests/sched_ext/scx_test.h |
Defines test framework API. |
tools/testing/selftests/sched_ext/runner.c |
Runs sched_ext tests. |
tools/testing/selftests/sched_ext/reload_loop.c |
Adds reload stress test. |
tools/testing/selftests/sched_ext/prog_run.c |
Tests BPF_PROG_RUN integration. |
tools/testing/selftests/sched_ext/prog_run.bpf.c |
Implements syscall BPF test. |
tools/testing/selftests/sched_ext/minimal.c |
Tests minimal scheduler loading. |
tools/testing/selftests/sched_ext/minimal.bpf.c |
Defines minimal scheduler. |
tools/testing/selftests/sched_ext/maybe_null.c |
Tests nullable callback arguments. |
tools/testing/selftests/sched_ext/maybe_null.bpf.c |
Implements valid nullable callbacks. |
tools/testing/selftests/sched_ext/maybe_null_fail_yld.bpf.c |
Tests invalid yield dereference. |
tools/testing/selftests/sched_ext/maybe_null_fail_dsp.bpf.c |
Tests invalid dispatch dereference. |
tools/testing/selftests/sched_ext/maximal.c |
Tests maximal scheduler loading. |
tools/testing/selftests/sched_ext/maximal.bpf.c |
Defines all scheduler callbacks. |
tools/testing/selftests/sched_ext/init_enable_count.c |
Verifies lifecycle callback counts. |
tools/testing/selftests/sched_ext/init_enable_count.bpf.c |
Counts lifecycle callbacks. |
tools/testing/selftests/sched_ext/hotplug.c |
Tests CPU hotplug behavior. |
tools/testing/selftests/sched_ext/hotplug.bpf.c |
Implements hotplug scheduler. |
tools/testing/selftests/sched_ext/hotplug_test.h |
Shares hotplug test flags. |
tools/testing/selftests/sched_ext/exit.c |
Tests scheduler exit paths. |
tools/testing/selftests/sched_ext/exit.bpf.c |
Triggers scheduler exits. |
tools/testing/selftests/sched_ext/exit_test.h |
Defines exit test cases. |
tools/testing/selftests/sched_ext/enq_select_cpu_fails.c |
Tests prohibited helper usage. |
tools/testing/selftests/sched_ext/enq_select_cpu_fails.bpf.c |
Calls selection helper from enqueue. |
tools/testing/selftests/sched_ext/enq_last_no_enq_fails.c |
Tests invalid ENQ_LAST configuration. |
tools/testing/selftests/sched_ext/enq_last_no_enq_fails.bpf.c |
Defines invalid scheduler flags. |
tools/testing/selftests/sched_ext/dsp_local_on.c |
Tests remote local-DSQ dispatch. |
tools/testing/selftests/sched_ext/dsp_local_on.bpf.c |
Implements local-on dispatch. |
tools/testing/selftests/sched_ext/ddsp_vtimelocal_fail.c |
Tests invalid vtime dispatch. |
tools/testing/selftests/sched_ext/ddsp_vtimelocal_fail.bpf.c |
Triggers local vtime failure. |
tools/testing/selftests/sched_ext/ddsp_bogus_dsq_fail.c |
Tests bogus DSQ fallback. |
tools/testing/selftests/sched_ext/ddsp_bogus_dsq_fail.bpf.c |
Dispatches to bogus DSQ. |
tools/testing/selftests/sched_ext/create_dsq.c |
Tests DSQ lifecycle. |
tools/testing/selftests/sched_ext/create_dsq.bpf.c |
Creates and destroys DSQs. |
tools/testing/selftests/sched_ext/config |
Enables required test config. |
tools/testing/selftests/sched_ext/.gitignore |
Ignores generated test files. |
tools/testing/selftests/bpf/progs/verifier_spin_lock.c |
Updates verifier expectation. |
tools/testing/selftests/bpf/progs/test_global_func5.c |
Updates verifier message. |
tools/testing/selftests/bpf/progs/test_global_func_ctx_args.c |
Handles s390 context types. |
tools/testing/selftests/bpf/progs/task_kfunc_failure.c |
Updates kfunc failure expectation. |
tools/testing/selftests/bpf/progs/cgrp_kfunc_failure.c |
Updates cgroup verifier expectation. |
tools/testing/selftests/bpf/prog_tests/log_fixup.c |
Adjusts log truncation tests. |
tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c |
Registers test struct_ops types. |
tools/testing/selftests/bpf/bpf_test_no_cfi/bpf_test_no_cfi.c |
Tests missing CFI stubs. |
tools/sched_ext/scx_simple.c |
Adds simple scheduler frontend. |
tools/sched_ext/scx_simple.bpf.c |
Implements simple scheduler. |
tools/sched_ext/scx_show_state.py |
Displays sched_ext state. |
tools/sched_ext/scx_qmap.c |
Adds qmap scheduler frontend. |
tools/sched_ext/scx_flatcg.h |
Defines flat-cgroup state. |
tools/sched_ext/scx_central.c |
Adds central scheduler frontend. |
tools/sched_ext/include/scx/user_exit_info.h |
Defines exit reporting API. |
tools/sched_ext/include/scx/common.h |
Adds userspace helper API. |
tools/sched_ext/include/bpf-compat/gnu/stubs.h |
Adds BPF build compatibility stub. |
tools/sched_ext/.gitignore |
Ignores generated scheduler files. |
tools/Makefile |
Integrates sched_ext tools. |
tools/include/uapi/linux/bpf.h |
Synchronizes BPF UAPI. |
net/xfrm/xfrm_interface_bpf.c |
Uses kfunc definition guards. |
net/socket.c |
Uses BPF hook guards. |
net/netfilter/nf_nat_bpf.c |
Uses kfunc definition guards. |
net/netfilter/nf_conntrack_bpf.c |
Uses kfunc definition guards. |
net/ipv4/tcp_cong.c |
Updates congestion-control replacement. |
net/ipv4/fou_bpf.c |
Uses kfunc definition guards. |
net/ipv4/bpf_tcp_ca.c |
Modernizes TCP struct_ops registration. |
net/core/xdp.c |
Uses kfunc definition guards. |
net/core/filter.c |
Updates common helper availability. |
net/bpf/test_run.c |
Uses kfunc definition guards. |
net/bpf/bpf_dummy_struct_ops.c |
Registers dummy struct_ops. |
mm/vmalloc.c |
Adds sparse vmalloc mapping. |
Makefile |
Propagates tool verbosity. |
MAINTAINERS |
Adds sched_ext ownership. |
lib/dump_stack.c |
Includes sched_ext diagnostics. |
kernel/watchdog.c |
Ejects stalled BPF schedulers. |
kernel/trace/bpf_trace.c |
Updates tracing BPF helpers. |
kernel/sched/syscalls.c |
Integrates SCHED_EXT policy. |
kernel/sched/stop_task.c |
Updates scheduler class interface. |
kernel/sched/rt.c |
Updates RT class interface. |
kernel/sched/pelt.h |
Declares non-fair load updates. |
kernel/sched/pelt.c |
Implements non-fair load updates. |
kernel/sched/idle.c |
Integrates sched_ext idle tracking. |
kernel/sched/ext.h |
Declares sched_ext scheduler hooks. |
kernel/sched/debug.c |
Reports sched_ext task state. |
kernel/sched/deadline.c |
Updates deadline class interface. |
kernel/sched/cpufreq_schedutil.c |
Integrates sched_ext CPU targets. |
kernel/sched/build_policy.c |
Builds sched_ext implementation. |
kernel/sched/autogroup.c |
Updates task migration calls. |
kernel/Kconfig.preempt |
Adds sched_ext configuration. |
kernel/fork.c |
Integrates sched_ext task lifecycle. |
kernel/events/core.c |
Uses program sleepable state. |
kernel/cgroup/rstat.c |
Uses BPF hook guards. |
kernel/cgroup/cgroup.c |
Preserves interrupt state in iterators. |
kernel/bpf/trampoline.c |
Uses program sleepable state. |
kernel/bpf/tnum.c |
Adds subregister composition. |
kernel/bpf/map_iter.c |
Uses kfunc definition guards. |
kernel/bpf/Makefile |
Builds BPF arena support. |
kernel/bpf/local_storage.c |
Simplifies sequence output. |
kernel/bpf/helpers.c |
Extends helpers and kfuncs. |
kernel/bpf/hashtab.c |
Simplifies sequence output. |
kernel/bpf/disasm.c |
Decodes new BPF instructions. |
kernel/bpf/cpumask.c |
Adds cpumask weight kfunc. |
kernel/bpf/core.c |
Adds arena and JIT support. |
kernel/bpf/cgroup.c |
Consolidates common helpers. |
kernel/bpf/bpf_struct_ops_types.h |
Removes static struct_ops list. |
kernel/bpf/bpf_iter.c |
Updates iterator behavior. |
kernel/bpf/arraymap.c |
Simplifies sequence output. |
init/Kconfig |
Adds EXT group scheduling. |
init/init_task.c |
Initializes sched_ext task state. |
include/uapi/linux/sched.h |
Exposes SCHED_EXT policy. |
include/uapi/linux/bpf.h |
Extends BPF UAPI. |
include/trace/events/sched_ext.h |
Adds sched_ext tracepoint. |
include/linux/vmalloc.h |
Exposes sparse vmalloc API. |
include/linux/tnum.h |
Declares subregister composition. |
include/linux/sched/task.h |
Updates fork scheduler API. |
include/linux/sched.h |
Embeds sched_ext task state. |
include/linux/filter.h |
Adds arena instruction modes. |
include/linux/cgroup.h |
Refactors iterator flags. |
include/linux/btf.h |
Extends kfunc and struct_ops APIs. |
include/linux/btf_ids.h |
Adds kfunc BTF sets. |
include/linux/bpf_types.h |
Registers arena map type. |
include/asm-generic/vmlinux.lds.h |
Orders sched_ext class. |
drivers/tty/sysrq.c |
Reserves sched_ext reset key. |
Documentation/scheduler/index.rst |
Links sched_ext documentation. |
Documentation/bpf/kfuncs.rst |
Documents kfunc guard macros. |
Documentation/bpf/cpumasks.rst |
Documents cpumask weight. |
arch/x86/configs/deepin_x86_desktop_defconfig |
Enables sched_ext by default. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| #ifdef CONFIG_SCHED_CLASS_EXT | ||
| struct sched_ext_entity scx; | ||
| #endif |
| cpuset = CPU_ALLOC(skel->rodata->nr_cpu_ids); | ||
| SCX_BUG_ON(!cpuset, "Failed to allocate cpuset"); | ||
| CPU_ZERO(cpuset); | ||
| CPU_SET(skel->rodata->central_cpu, cpuset); | ||
| SCX_BUG_ON(sched_setaffinity(0, sizeof(cpuset), cpuset), | ||
| "Failed to affinitize to central CPU %d (max %d)", | ||
| skel->rodata->central_cpu, skel->rodata->nr_cpu_ids - 1); | ||
| CPU_FREE(cpuset); |
| if (UEI_ECODE_RESTART(ecode)) | ||
| goto restart; |
| } | ||
| } | ||
|
|
||
| for (i = 0; i < __scx_num_tests; i++) { |
| ret = sprintf(buf, "%lu", val); | ||
| if (ret < 0) | ||
| return ret; | ||
|
|
||
| if (write_text(path, buf, sizeof(buf)) <= 0) | ||
| return -1; |


sched_ext(可扩展调度器)是Linux内核引入的一种新型CPU调度框架,允许开发者利用eBPF技术编写自定义调度策略,无需修改内核源码即可动态替换默认调度器。它以内核模块形式运行,但高度依赖用户空间工具协同,该PR从Linux 6.18 LTS内核backport下了完整的sched_ext实现,可直接与scx和scx-loader用户空间组件一起工作。
要使用sched_ext,需要内核和用户空间同时安装scx和scx-loader。首先,内核必须启用CONFIG_SCHED_CLASS_EXT配置,集成scx核心支持。其次,用户空间需安装scx软件包,它提供了多种现成的eBPF调度器程序(如scx_simple等);同时必须安装scx-loader,作为用户态守护进程,负责将选定的调度器安全地加载到内核、处理生命周期管理及故障回退。只有内核组件与用户空间的scx、scx-loader完整配合,才能灵活切换调度策略,实现性能调优。