Messages in this thread | | | From | Valentin Schneider <> | Subject | Re: [PATCH v2 0/4] Fix put_task_struct() calls under PREEMPT_RT | Date | Fri, 20 Jan 2023 17:45:01 +0000 |
| |
On 20/01/23 12:02, Wander Lairson Costa wrote: > put_task_struct() decrements a usage counter and calls > __put_task_struct() if the counter reaches zero. > > __put_task_struct() indirectly acquires a spinlock, which is a sleeping > lock under PREEMPT_RT. Therefore, we can't call put_task_struct() in an > atomic context in RT kernels. > > This patch series introduces put_task_struct_atomic_safe(), which defers > the call to __put_task_struct() to a process context when compiled with > PREEMPT_RT. > > It also fixes known problematic call sites. >
Browsing around put_task_struct() callsites gives me the impression there are more problematic call sites lurking around, which makes me wonder: should we make the PREEMPT_RT put_task_struct() *always* be done via call_rcu()?
The task's stack is actually always freed that way in put_task_stack(), cf.
e540bf3162e8 ("fork: Only cache the VMAP stack in finish_task_switch()")
> Changelog: > ========== > > v2: > * Add the put_task_struct_atomic_safe() function that is responsible for > handling the conditions to call put_task_struct(). > * Replace put_task_struct() by put_task_struct_atomic_safe() in known > atomic call sites. > > Wander Lairson Costa (4): > sched/task: Add the put_task_struct_atomic_safe function > sched/deadline: fix inactive_task_timer splat > sched/rt: use put_task_struct_atomic_safe() to avoid potential splat > sched/core: use put_task_struct_atomic_safe() to avoid potential splat > > include/linux/sched/task.h | 21 +++++++++++++++++++++ > kernel/fork.c | 8 ++++++++ > kernel/sched/core.c | 2 +- > kernel/sched/deadline.c | 2 +- > kernel/sched/rt.c | 4 ++-- > 5 files changed, 33 insertions(+), 4 deletions(-) > > -- > 2.39.0
| |