Re: [PATCH 2/2] selftests/sched_ext: Add lazy preemption tests

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The ENQ_BOTH scenario in the `kick` selftest hangs indefinitely on single-CPU systems due to starvation of the main test process.
--

commit 54a68e6d559e121241b4e1714f59dcb8d2d45246
Author: Andrea Righi <arighi@nvidia.com>

selftests/sched_ext: Add lazy preemption tests

This commit adds trace-based coverage for immediate and lazy preemption.
It exercises kick requests individually and combined, and extends the
NO_HZ_FULL test with infinite-slice victims.

> diff --git a/tools/testing/selftests/sched_ext/kick.bpf.c b/tools/testing/selftests/sched_ext/kick.bpf.c
> new file mode 100644
> index 0000000000000..03ddc44faf5c4
> --- /dev/null
> +++ b/tools/testing/selftests/sched_ext/kick.bpf.c
[ ... ]
> +void BPF_STRUCT_OPS(kick_enqueue, struct task_struct *p, u64 enq_flags)
> +{
> +	switch (scenario) {
> +	case ENQ_BOTH:
> +		if (p->pid == victim_pid) {
> +			scx_bpf_dsq_insert(p, SCX_DSQ_GLOBAL, SCX_SLICE_INF,
> +					   enq_flags);
[Severity: Medium]
Will this assignment of SCX_SLICE_INF to the victim task starve the main
test process and hang the test indefinitely on single-CPU systems?

When the main test process shares the CPU with the victim, its usleep()
timer wakeup inadvertently consumes the KICK_STATE_QUEUED state, advancing
the test state to KICK_STATE_DONE. When it sleeps again inside
wait_for_state(), it is awoken but enqueued into the global DSQ without
preemption flags (since the state is no longer QUEUED). Because the victim
task runs with SCX_SLICE_INF, it is never preempted by the tick, starving
the main test process forever.

> +		} else if (state == KICK_STATE_QUEUED) {
> +			scx_bpf_dsq_insert(p, SCX_DSQ_LOCAL, SCX_SLICE_DFL,
> +					   enq_flags | SCX_ENQ_PREEMPT |
> +					   SCX_ENQ_PREEMPT_LAZY);
> +		} else {
[ ... ]
> diff --git a/tools/testing/selftests/sched_ext/kick.c b/tools/testing/selftests/sched_ext/kick.c
> new file mode 100644
> index 0000000000000..b7af2683c2728
> --- /dev/null
> +++ b/tools/testing/selftests/sched_ext/kick.c
[ ... ]
> +static enum scx_test_status trace_one(u32 scenario, u64 ops_flags,
> +				      s32 slice_expiry_override,
> +				      struct observation *obs)
> +{
> +	struct bpf_link *ops_link = NULL;
> +	struct kick *skel = NULL;
> +	struct victim challenger = { .pid = -1, .start_fd = -1 };
> +	struct victim victim;
> +	enum scx_test_status ret = SCX_TEST_FAIL;
> +	int cpu = pick_target_cpu();
[Severity: Medium]
Should we migrate the main test process away from this target CPU, or skip
the test if a second housekeeping CPU is unavailable (similar to the
behavior in nohz_tick.c)?

If the main test process runs on the same CPU as the victim task, it can be
starved by the victim task receiving an infinite time slice during the
ENQ_BOTH scenario, causing the test to hang indefinitely.

> +
> +	if (cpu < 0) {
> +		SCX_ERR("No available CPU");
> +		return SCX_TEST_FAIL;
> +	}
> +	victim = spawn_victim(cpu);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914144620.2032614-1-arighi@nvidia.com?part=2