Re: [PATCH v2 2/2] sched_ext: Fix exit_cpu accuracy for lockup paths

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] synchronize_rcu_expedited_wait() incorrectly passes the detector CPU instead of the stalled CPU or -1 to panic_on_rcu_stall().
--

commit be51680372265a1376da290cd206c8c990bc5343
Author: Cheng-Yang Chou <yphbchou0911@gmail.com>

sched_ext: Fix exit_cpu accuracy for lockup paths

This commit updates lockup detection paths to pass the actually stalled CPU,
rather than the CPU executing the detection code, to handle_lockup(). It
modifies scx_hardlockup_irq_workfn(), scx_rcu_cpu_stall(), and
panic_on_rcu_stall() to accept the stalled CPU as an argument.

[ ... ]

> diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
> index 82cada459e5d0..fa83e273a6487 100644
> --- a/kernel/rcu/tree_exp.h
> +++ b/kernel/rcu/tree_exp.h
> @@ -675,7 +675,7 @@ static void synchronize_rcu_expedited_wait(void)
>  
>  		nbcon_cpu_emergency_exit();
>  
> -		panic_on_rcu_stall();
> +		panic_on_rcu_stall(raw_smp_processor_id());

The commit message states that recording the detector CPU rather than the
stalled CPU is wrong.

However, in synchronize_rcu_expedited_wait(), it appears raw_smp_processor_id()
represents the CPU waiting for the expedited grace period (the detector CPU),
not necessarily the CPU that is stalled.

Does passing raw_smp_processor_id() here contradict the patch's stated goal
by incorrectly blaming the detecting CPU? If identifying a specific stalled
CPU is difficult in this path, would it be more appropriate to pass -1 to
indicate no specific CPU is targeted?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260504161543.674488-1-yphbchou0911@gmail.com?part=2