Re: [PATCH 1/2] sched_ext: Add lazy preemption support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] SCX_KICK_WAIT synchronization fails permanently when combined with SCX_KICK_PREEMPT_LAZY because the synchronization return flag is completely discarded.
--

commit 9fb7f95cc0c5449c9ecc76666403b400b99be566
Author: Andrea Righi <arighi@nvidia.com>

sched_ext: Add lazy preemption support

This commit introduces lazy preemption support for sched_ext by adding
SCX_ENQ_PREEMPT_LAZY and SCX_KICK_PREEMPT_LAZY. It updates the tick logic
and dispatch queues to handle lazy rescheduling correctly while preserving
precedence for immediate preemption and wait requests.

> diff --git a/kernel/sched/ext/ext.c b/kernel/sched/ext/ext.c
> --- a/kernel/sched/ext/ext.c
> +++ b/kernel/sched/ext/ext.c
[ ... ]
> @@ -8572,6 +8624,14 @@ static void kick_cpus_irq_workfn(struct irq_work *irq_work)
>  			cpumask_clear_cpu(cpu, pcpu->cpus_to_kick_if_idle);
>  		}
>  
> +		/*
> +		 * kick_one_cpu() clears the lazy bit of every cpu it visited
> +		 * above; visit the remaining requests which contain lazy
> +		 * preemption, see scx_kick_cpu().
> +		 */
> +		for_each_cpu(cpu, pcpu->cpus_to_preempt_lazy)
> +			kick_one_cpu(cpu, pcpu, this_rq, ksyncs);

[Severity: High]
When SCX_KICK_WAIT is combined with SCX_KICK_PREEMPT_LAZY, does this
discard the wait synchronization requirement?

kick_one_cpu() returns a boolean indicating whether synchronization is
required. In the primary loop above, the result is accumulated into
should_wait, but here the return value is ignored. If a CPU is only
processed in this lazy preemption loop, the caller might proceed
prematurely, breaking the SCX_KICK_WAIT guarantees.

[ ... ]
> @@ -9591,12 +9683,15 @@ void scx_kick_cpu(struct scx_sched *sch, s32 cpu, u64 flags)
>  		}
>  		cpumask_set_cpu(cpu, pcpu->cpus_to_kick_if_idle);
>  	} else {
> -		cpumask_set_cpu(cpu, pcpu->cpus_to_kick);
> -
> +		/* Accumulate requests and resolve their precedence at delivery. */
>  		if (flags & SCX_KICK_PREEMPT)
>  			cpumask_set_cpu(cpu, pcpu->cpus_to_preempt);
> +		if (flags & SCX_KICK_PREEMPT_LAZY)
> +			cpumask_set_cpu(cpu, pcpu->cpus_to_preempt_lazy);
>  		if (flags & SCX_KICK_WAIT)
>  			cpumask_set_cpu(cpu, pcpu->cpus_to_wait);
> +		if (!(flags & SCX_KICK_PREEMPT_LAZY))
> +			cpumask_set_cpu(cpu, pcpu->cpus_to_kick);

[Severity: High]
Does skipping the assignment to cpus_to_kick when SCX_KICK_PREEMPT_LAZY
is set force the CPU to be processed exclusively in the secondary loop in
kick_cpus_irq_workfn()?

Because the CPU is omitted from cpus_to_kick here, it bypasses the primary
loop where should_wait is accumulated. Instead, it gets handled entirely
in the cpus_to_preempt_lazy loop where the return value of kick_one_cpu()
is ignored, preventing the wait request from being properly respected.

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