Re: [syzbot] [mm?] INFO: rcu detected stall in khugepaged (3)

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 5 Aug 2026 13:28:16 -0700 "Paul E. McKenney" <paulmck@kernel.org> wrote:

> > collapse_scan_file()'s main loop has
> > 
> > 		if (need_resched()) {
> > 			xas_pause(&xas);
> > 			cond_resched_rcu();
> > 		}
> > 
> > but that won't help with the RCU stall detector(?).
> > 
> > I suggest that a suitable fix here would be to add the analogous
> > 
> > 	if (rcu_i_need_to_take_a_break()) {
> > 		rcu_read_unlock();
> > 		rcu_take_a_break())	
> > 		rcu_read_lock();
> > 	}
> > 
> > (iirc rcu_read_unlock() does an rcu run, so rcu_take_a_break() isn't
> > needed here)
> > 
> > Paul, wdyt?
> 
> Let's see...
> 
> The console log says "rcu_preempt detected stalls on CPUs/tasks",
> which means that cond_resched() is a no-op, but it also means that
> the rcu_read_unlock() in cond_resched_rcu() will directly take care of
> informing RCU of the pause.
> 
> But that is clearly not happening.  Why?
> 
> Well, we have this:
> 
> rcu: 	Tasks blocked on level-0 rcu_node (CPUs 0-1): P37/1:b..l
> 
> This means that the task whose RCU read-side critical section is blocking
> the current RCU grace period isn't even running, and thus cannot invoke
> cond_resched_rcu(), let alone the rcu_read_unlock() within that function.
> So an RCU CPU stall warning is expected behavior.  Or at least it is not
> in any way ruled out.
> 
> What we need is RCU priority boosting.

Do we?  I'm suggesting we need need_resched_rcu()!

> Except that the .config file
> does not enable this.  Not only is there no CONFIG_RCU_BOOST=y, there
> is also no CONFIG_RCU_EXPERT=y and no CONFIG_PREEMPT_RT=y.  But there
> is CONFIG_RT_MUTEX=y and CONFIG_RCU_EXPERT=y.
> 
> Because we don't have RCU priority boosting, if the load on the system
> is heavy enough to prevent our poor preempted RCU reader (PID 37) from
> running, the grace period cannot end.
> 
> I am not sure why this task is saving its stack, but maybe that is normal
> for this code path?
> 
> My bemusement aside, I recommend running this test either with
> non-preemptible RCU (CONFIG_PREEMPT_LAZY=y these days) or enabling RCU
> priority boosting (CONFIG_RCU_EXPERT=y and CONFIG_RCU_BOOST=y).
> 
> Maybe RCU_BOOST should no longer depend on RCU_EXPERT?  I would of
> course need ot remove the prompt ("Enable RCU priority boosting") to
> avoid annoying Linus.  Maybe as shown below.
> 
> Thoughts?

If I'm understanding correctly, this workload is busted with this
config and the proposed fix is to alter the config?  Well, why are we
permitting that config at all?

Seems to me that a solution to permit this config to work is very
simple.  Something like:

	time_t start;

	rcu_read_lock();
	start = current_time();

	for (lots of work) {
		...
		if (need_resched_rcu(start)) {
			cond_resched_rcu();
			start = current_time();
	}

Where need_resched_rcu() tests to see if we're getting close to hitting
the watchdog timeout.

No?