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

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?