[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250410122002.JxN9F-nE@linutronix.de>
Date: Thu, 10 Apr 2025 14:20:02 +0200
From: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To: "Luis Claudio R. Goncalves" <lgoncalv@...hat.com>
Cc: Clark Williams <clrkwllms@...nel.org>,
Steven Rostedt <rostedt@...dmis.org>, Tejun Heo <tj@...nel.org>,
David Vernet <dvernet@...a.com>, Barret Rhoden <brho@...gle.com>,
Josh Don <joshdon@...gle.com>, Crystal Wood <crwood@...hat.com>,
linux-kernel@...r.kernel.org, linux-rt-devel@...ts.linux.dev,
Juri Lelli <juri.lelli@...hat.com>, Ben Segall <bsegall@...gle.com>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Ingo Molnar <mingo@...hat.com>, Mel Gorman <mgorman@...e.de>,
Peter Zijlstra <peterz@...radead.org>,
Valentin Schneider <vschneid@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Thomas Gleixner <tglx@...utronix.de>, lclaudio00@...il.com
Subject: Re: [PATCH v3] sched: do not call __put_task_struct() on rt if
pi_blocked_on is set
On 2025-04-10 09:10:12 [-0300], Luis Claudio R. Goncalves wrote:
> diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h
> --- a/include/linux/sched/task.h
> +++ b/include/linux/sched/task.h
> @@ -134,22 +134,12 @@ 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
> + * In !RT, it is always safe to call __put_task_struct(),
> + * but 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).
> *
> * call_rcu() will schedule delayed_put_task_struct_rcu()
> * to be called in process context.
Did you test it with lockdep with and without PREEMPT_RT? It would be
nice to throw some testing on it.
This comment here "call_rcu will schedule bla in process context" is
wrong. It will schedule the callback in softirq context. Unless RCU is
configured to run the callbacks in rcuc/ thread which is the default for
PREEMPT_RT. Also delayed_put_task_struct_rcu() does not exist, imho
never did.
Sebastian
Powered by blists - more mailing lists