lkml.org 
[lkml]   [2023]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v2 0/4] Fix put_task_struct() calls under PREEMPT_RT
Date
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

\
 
 \ /
  Last update: 2023-03-26 23:49    [W:0.115 / U:3.352 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site