Re: [PATCH 2/2] sched_ext, rcu: Upgrade RCU stall paths to report cpumask of stalled CPUs

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Dynamic memory allocation (`GFP_ATOMIC`) in the RCU stall detector path can cause a hard deadlock, masking the system hang instead of reporting it.
--

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

sched_ext, rcu: Upgrade RCU stall paths to report cpumask of stalled CPUs

This commit updates the RCU stall paths to capture all stalled CPUs in a
cpumask rather than just the detecting CPU. The cpumask is passed through
the stall handlers and dumped first during a sched_ext state dump to avoid
losing the stalled CPUs to truncation.

> diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
> index 82cada459e5d0..b8f4ca984c1c9 100644
> --- a/kernel/rcu/tree_exp.h
> +++ b/kernel/rcu/tree_exp.h

[ ... ]

> @@ -659,23 +662,28 @@ static void synchronize_rcu_expedited_wait(void)
>  
>  	for (;;) {
>  		unsigned long j;
> +		cpumask_var_t stalled_mask;
> +		bool have_mask;
>  
>  		if (synchronize_rcu_expedited_wait_once(jiffies_stall))
>  			return;
>  		if (rcu_stall_is_suppressed())
>  			continue;
>  
> +		have_mask = zalloc_cpumask_var(&stalled_mask, GFP_ATOMIC | __GFP_NOWARN);
> +

[Severity: High]
Could this allocation cause a hard deadlock during an RCU stall?

If CONFIG_CPUMASK_OFFSTACK=y is set, zalloc_cpumask_var() performs a dynamic
memory allocation via kmalloc(). If the stalled CPU is stuck holding a memory
allocator lock (such as zone->lock or the SLUB list_lock), the detecting CPU
will deadlock trying to acquire it.

Additionally, GFP_ATOMIC includes __GFP_KSWAPD_RECLAIM, which can wake up
kswapd and acquire scheduler locks (pi_lock, rq->lock). If the stalled
CPU holds one of these scheduler locks, it could also deadlock here.

This would completely prevent the RCU stall warning from being printed
and mask the root cause of the hang. Would it be safer to use a
statically preallocated cpumask for stall reporting?

>  		nbcon_cpu_emergency_enter();
>  
>  		j = jiffies;

[ ... ]

> diff --git a/kernel/rcu/tree_stall.h b/kernel/rcu/tree_stall.h
> index b67532cb87705..90d6eaf1b8415 100644
> --- a/kernel/rcu/tree_stall.h
> +++ b/kernel/rcu/tree_stall.h

[ ... ]

> @@ -645,6 +647,8 @@ static void print_other_cpu_stall(unsigned long gp_seq, unsigned long gps)
>  	if (rcu_stall_is_suppressed())
>  		return;
>  
> +	have_mask = zalloc_cpumask_var(&stalled_mask, GFP_ATOMIC | __GFP_NOWARN);
> +

[Severity: High]
Can this dynamic allocation also trigger a hard deadlock?

print_other_cpu_stall() executes in a critical diagnostic context with
IRQs disabled (enforced by lockdep_assert_irqs_disabled()). Similar to
the issue in synchronize_rcu_expedited_wait(), allocating memory here
might deadlock if the stalled CPU holds a lock required by the memory
allocator or scheduler.

>  	nbcon_cpu_emergency_enter();
>  
>  	/*

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