On Fri, Aug 08, 2025 at 07:27:26PM -0400, Sasha Levin wrote:

This is a note to let you know that I've just added the patch titled

sched: Do not call __put_task_struct() on rt if pi_blocked_on is set

to the 6.16-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...

The filename of the patch is: sched-do-not-call-__put_task_struct-on-rt-if-pi_bloc.patch and it can be found in the queue-6.16 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let stable@vger.kernel.org know about it.

Hi Sasha!

I am the author of that patch and I sent a follow-up patch that fixes a mistake I made on the original patch:

[RESEND PATCH] sched: restore the behavior of put_task_struct() for non-rt https://lore.kernel.org/all/aJOwe_ZS5rHXMrsO@uudg.org/

The patch you have does not match what is in the description. I unfortunately sent the wrong version of the patch on the verge of leaving for a long vacation and only noticed that when I returned. The code is correct, but does not match the commit description and is a change that I would like to propose later as an RFC, not the simpler bugfix originally intended.

I suggest waiting for the follow-up patch mentioned above to include both on stable kernels.

Sorry for the inconvenience, Luis

commit 7bed29f5ad955444283dca82476dd92c59923f73 Author: Luis Claudio R. Goncalves lgoncalv@redhat.com Date: Mon Jul 7 11:03:59 2025 -0300

sched: Do not call __put_task_struct() on rt if pi_blocked_on is set

[ Upstream commit 8671bad873ebeb082afcf7b4501395c374da6023 ] 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); This is not a SCHED_EXT bug. The first cleanup function called by __put_task_struct() is sched_ext_free() and it happens to take a (RT) spin_lock, which in the scenario described above, would trigger the lockdep assertion of "!current->pi_blocked_on". Crystal Wood was able to identify the problem as __put_task_struct() being called during rt_mutex_adjust_prio_chain(), in the context of a process with a mutex enqueued. Instead of adding more complex conditions to decide when to directly call __put_task_struct() and when to defer the call, unconditionally resort to the deferred call on PREEMPT_RT to simplify the code. Fixes: 893cdaaa3977 ("sched: avoid false lockdep splat in put_task_struct()") Suggested-by: Crystal Wood crwood@redhat.com Signed-off-by: Luis Claudio R. Goncalves lgoncalv@redhat.com Signed-off-by: Peter Zijlstra (Intel) peterz@infradead.org Reviewed-by: Wander Lairson Costa wander@redhat.com Reviewed-by: Valentin Schneider vschneid@redhat.com Reviewed-by: Sebastian Andrzej Siewior bigeasy@linutronix.de Link: https://lore.kernel.org/r/aGvTz5VaPFyj0pBV@uudg.org Signed-off-by: Sasha Levin sashal@kernel.org

diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h index ca1db4b92c32..58ce71715268 100644 --- a/include/linux/sched/task.h +++ b/include/linux/sched/task.h @@ -135,24 +135,17 @@ static inline void put_task_struct(struct task_struct *t) return; /*

• * In !RT, it is always safe to call __put_task_struct().
  

• * Under RT, we can only call it in preemptible context.
  

• */
  

• if (!IS_ENABLED(CONFIG_PREEMPT_RT) || preemptible()) {

• static DEFINE_WAIT_OVERRIDE_MAP(put_task_map, LD_WAIT_SLEEP);
  

• lock_map_acquire_try(&put_task_map);
  

• __put_task_struct(t);
  

• lock_map_release(&put_task_map);
  

• return;
  

• }
• /*

• * under PREEMPT_RT, we can't call put_task_struct
  

• * Under PREEMPT_RT, we can't call __put_task_struct
  

  • in atomic context because it will indirectly

• * acquire sleeping locks.
  

• * acquire sleeping locks. The same is true if the
  

• * current process has a mutex enqueued (blocked on
  

• * a PI chain).
  

• *
  

• * In !RT, it is always safe to call __put_task_struct().
  

• * Though, in order to simplify the code, resort to the
  

• * deferred call too.
  

• * call_rcu() will schedule delayed_put_task_struct_rcu()
  

• * call_rcu() will schedule __put_task_struct_rcu_cb()
  

  • to be called in process context.
  • __put_task_struct() is called when

@@ -165,7 +158,7 @@ static inline void put_task_struct(struct task_struct *t) * * delayed_free_task() also uses ->rcu, but it is only called * when it fails to fork a process. Therefore, there is no

• * way it can conflict with put_task_struct().
  

• * way it can conflict with __put_task_struct().
  

  */ call_rcu(&t->rcu, __put_task_struct_rcu_cb);

}

---end quoted text---