Re: [PATCH v2] sched: do not call __put_task_struct() on rt if pi_blocked_on is set

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Apr 10, 2025 at 08:48:44AM +0200, Sebastian Andrzej Siewior wrote:
> + sched folks.
> 
> On 2025-04-09 15:58:32 [-0300], Luis Claudio R. Goncalves wrote:
> > With PREEMPT_RT enabled, some of the calls to put_task_struct() coming
> > from rt_mutex_adjust_prio_chain() could happen in preemptible context and
> > with a mutex enqueued. That could lead to this sequence:
> > 
> > 	rt_mutex_adjust_prio_chain()
> > 	  put_task_struct()
> > 	    __put_task_struct()
> > 	      sched_ext_free()
> > 	        spin_lock_irqsave()
> > 	          rtlock_lock() --->  TRIGGERS
> > 	                              lockdep_assert(!current->pi_blocked_on);
> > 
> > Adjust the check in put_task_struct() to also consider pi_blocked_on before
> > calling __put_task_struct(), resorting to the deferred call in case it is
> > set.
> > 
> > v2: Rostedt suggested removing the #ifdef from put_task_struct() and
> >     creating tsk_is_pi_blocked_on() in sched.h to make the change cleaner.

Oh gawd, this patch makes a sad situation worse.

> I complained about this special RT case in put_task_struct() when it was
> first got introduced. Couldn't we just just unconditionally do the RCU
> put?

Yeah, please make it simpler, not more complex.