Re: [PATCH] mm/kmemleak: report RCU-tasks quiescent states during the scan

On Fri, Jul 31, 2026 at 11:07:44AM -0700, Breno Leitao wrote:
> On Thu, Jul 30, 2026 at 07:57:22AM -0700, Paul E. McKenney wrote:
> > > I suppose we want two things:
> > > 
> > > 1) change cond_resched() with cond_resched_tasks_rcu_qs()
> > > 2) Avoiding holding the ftrace lock while calling
> > >    synchronize_rcu_tasks()? It can take up to 10 minutes on a healthy
> > >    system to be releasd, right?
> > 
> > I do very much like both of those options.  ;-)
> > 
> > If #2 is impossible, would it make sense to have a mutex_lock_idle() or
> > similar in order to sanctify the lock synchronize_rcu_tasks() latencies?
> 
> How would mutex_lock_idle() differ from a regular mutex_lock() when
> sanctifying synchronize_rcu_tasks() latencies?

It would sleep at TASK_IDLE instead of TASK_UNINTERRUPTIBLE, as shown
below.  This would cause it to be ignored for hung-task purposes.

For a similar example, RCU uses swait_event_idle_exclusive() instead
of swait_event_exclusive() to avoid its grace-period kthread getting a
hung-task warning when the system doesn't need a grace period for more
than two minutes.

Yes, I did learn about this the hard way.  Why do you ask?  ;-)

The downside is that if some bug somewhere else under one of these mutexes
caused a too-long sleep, that too-long sleep would be silently ignored.
As always, choose wisely!

							Thanx, Paul

------------------------------------------------------------------------

static noinline void __sched
__mutex_lock_slowpath_idle(struct mutex *lock)
	__acquires(lock)
{
	__mutex_lock(lock, TASK_IDLE, 0, NULL, _RET_IP_);
	__acquire(lock);
}