* [PATCH v3] kernel/fork: beware of __put_task_struct calling context
@ 2023-02-01 12:45 Wander Lairson Costa
2023-02-02 18:37 ` Oleg Nesterov
0 siblings, 1 reply; 4+ messages in thread
From: Wander Lairson Costa @ 2023-02-01 12:45 UTC (permalink / raw)
To: Andrew Morton, Thomas Gleixner, Eric W. Biederman,
Andy Lutomirski, Sebastian Andrzej Siewior, Peter Zijlstra,
Liam R. Howlett, Fenghua Yu, Andrei Vagin, open list
Cc: Wander Lairson Costa, Hu Chunyu, Oleg Nesterov,
Valentin Schneider, Paul McKenney
Under PREEMPT_RT, __put_task_struct() indirectly acquires sleeping
locks. Therefore, it can't be called from an non-preemptible context.
One practical example is splat inside inactive_task_timer(), which is
called in a interrupt context:
CPU: 1 PID: 2848 Comm: life Kdump: loaded Tainted: G W ---------
Hardware name: HP ProLiant DL388p Gen8, BIOS P70 07/15/2012
Call Trace:
dump_stack_lvl+0x57/0x7d
mark_lock_irq.cold+0x33/0xba
? stack_trace_save+0x4b/0x70
? save_trace+0x55/0x150
mark_lock+0x1e7/0x400
mark_usage+0x11d/0x140
__lock_acquire+0x30d/0x930
lock_acquire.part.0+0x9c/0x210
? refill_obj_stock+0x3d/0x3a0
? rcu_read_lock_sched_held+0x3f/0x70
? trace_lock_acquire+0x38/0x140
? lock_acquire+0x30/0x80
? refill_obj_stock+0x3d/0x3a0
rt_spin_lock+0x27/0xe0
? refill_obj_stock+0x3d/0x3a0
refill_obj_stock+0x3d/0x3a0
? inactive_task_timer+0x1ad/0x340
kmem_cache_free+0x357/0x560
inactive_task_timer+0x1ad/0x340
? switched_from_dl+0x2d0/0x2d0
__run_hrtimer+0x8a/0x1a0
__hrtimer_run_queues+0x91/0x130
hrtimer_interrupt+0x10f/0x220
__sysvec_apic_timer_interrupt+0x7b/0xd0
sysvec_apic_timer_interrupt+0x4f/0xd0
? asm_sysvec_apic_timer_interrupt+0xa/0x20
asm_sysvec_apic_timer_interrupt+0x12/0x20
RIP: 0033:0x7fff196bf6f5
Instead of calling __put_task_struct() directly, we defer it using
call_rcu(). A more natural approach would use a workqueue, but since
in PREEMPT_RT, we can't allocate dynamic memory from atomic context,
the code would become more complex because we would need to put the
work_struct instance in the task_struct and initialize it when we
allocate a new task_struct.
Signed-off-by: Wander Lairson Costa <wander@redhat.com>
Reported-by: Hu Chunyu <chuhu@redhat.com>
Suggested-by: Oleg Nesterov <oleg@redhat.com>
Suggested-by: Valentin Schneider <vschneid@redhat.com>
Cc: Paul McKenney <paulmck@kernel.org>
---
kernel/fork.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 9f7fe3541897..b2d0d62c9b9d 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -840,7 +840,7 @@ static inline void put_signal_struct(struct signal_struct *sig)
free_signal_struct(sig);
}
-void __put_task_struct(struct task_struct *tsk)
+static void ___put_task_struct(struct task_struct *tsk)
{
WARN_ON(!tsk->exit_state);
WARN_ON(refcount_read(&tsk->usage));
@@ -857,6 +857,26 @@ void __put_task_struct(struct task_struct *tsk)
sched_core_free(tsk);
free_task(tsk);
}
+
+static void __delayed_put_task_struct(struct rcu_head *rhp)
+{
+ struct task_struct *task = container_of(rhp, struct task_struct, rcu);
+
+ ___put_task_struct(task);
+}
+
+void __put_task_struct(struct task_struct *tsk)
+{
+ if (IS_ENABLED(CONFIG_PREEMPT_RT) && (!preemptible() || !in_task()))
+ /*
+ * under PREEMPT_RT, we can't call put_task_struct
+ * in atomic context because it will indirectly
+ * acquire sleeping locks.
+ */
+ call_rcu(&tsk->rcu, __delayed_put_task_struct);
+ else
+ ___put_task_struct(tsk);
+}
EXPORT_SYMBOL_GPL(__put_task_struct);
void __init __weak arch_task_cache_init(void) { }
--
2.39.1
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v3] kernel/fork: beware of __put_task_struct calling context
2023-02-01 12:45 [PATCH v3] kernel/fork: beware of __put_task_struct calling context Wander Lairson Costa
@ 2023-02-02 18:37 ` Oleg Nesterov
2023-02-02 19:55 ` Wander Lairson Costa
0 siblings, 1 reply; 4+ messages in thread
From: Oleg Nesterov @ 2023-02-02 18:37 UTC (permalink / raw)
To: Wander Lairson Costa
Cc: Andrew Morton, Thomas Gleixner, Eric W. Biederman,
Andy Lutomirski, Sebastian Andrzej Siewior, Peter Zijlstra,
Liam R. Howlett, Fenghua Yu, Andrei Vagin, open list, Hu Chunyu,
Valentin Schneider, Paul McKenney
On 02/01, Wander Lairson Costa wrote:
>
> Instead of calling __put_task_struct() directly, we defer it using
> call_rcu(). A more natural approach would use a workqueue, but since
> in PREEMPT_RT, we can't allocate dynamic memory from atomic context,
> the code would become more complex because we would need to put the
> work_struct instance in the task_struct and initialize it when we
> allocate a new task_struct.
I don't think I can ack the changes in PREEMPT_RT but this version LGTM.
just a couple of purely cosmetic nits, feel free to ignore...
> +static void __delayed_put_task_struct(struct rcu_head *rhp)
> +{
> + struct task_struct *task = container_of(rhp, struct task_struct, rcu);
> +
> + ___put_task_struct(task);
> +}
We already have delayed_put_task_struct() which differs very much.
Perhaps something like ___put_task_struct() will look less confusing.
> +void __put_task_struct(struct task_struct *tsk)
> +{
> + if (IS_ENABLED(CONFIG_PREEMPT_RT) && (!preemptible() || !in_task()))
> + /*
> + * under PREEMPT_RT, we can't call put_task_struct
> + * in atomic context because it will indirectly
> + * acquire sleeping locks.
> + */
> + call_rcu(&tsk->rcu, __delayed_put_task_struct);
Perhaps this deserves additional note to explain why is it safe to use tsk->rcu
union. May be this is obvious, but I was confused when I looked at the previous
version ;)
but again, feel free to ignore.
Oleg.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v3] kernel/fork: beware of __put_task_struct calling context
2023-02-02 18:37 ` Oleg Nesterov
@ 2023-02-02 19:55 ` Wander Lairson Costa
2023-02-02 20:22 ` Oleg Nesterov
0 siblings, 1 reply; 4+ messages in thread
From: Wander Lairson Costa @ 2023-02-02 19:55 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Andrew Morton, Thomas Gleixner, Eric W. Biederman,
Andy Lutomirski, Sebastian Andrzej Siewior, Peter Zijlstra,
Liam R. Howlett, Fenghua Yu, Andrei Vagin, open list, Hu Chunyu,
Valentin Schneider, Paul McKenney
On Thu, Feb 2, 2023 at 3:37 PM, Oleg Nesterov <oleg@redhat.com> wrote:
>
> On 02/01, Wander Lairson Costa wrote:
> >
> > Instead of calling __put_task_struct() directly, we defer it using
> > call_rcu(). A more natural approach would use a workqueue, but since
> > in PREEMPT_RT, we can't allocate dynamic memory from atomic context,
> > the code would become more complex because we would need to put the
> > work_struct instance in the task_struct and initialize it when we
> > allocate a new task_struct.
>
> I don't think I can ack the changes in PREEMPT_RT but this version LGTM.
>
>
>
>
> just a couple of purely cosmetic nits, feel free to ignore...
>
> > +static void __delayed_put_task_struct(struct rcu_head *rhp)
> > +{
> > + struct task_struct *task = container_of(rhp, struct task_struct, rcu);
> > +
> > + ___put_task_struct(task);
> > +}
>
> We already have delayed_put_task_struct() which differs very much.
> Perhaps something like ___put_task_struct() will look less confusing.
>
___put_task_struct()? I already added a function with this name below.
> > +void __put_task_struct(struct task_struct *tsk)
> > +{
> > + if (IS_ENABLED(CONFIG_PREEMPT_RT) && (!preemptible() || !in_task()))
> > + /*
> > + * under PREEMPT_RT, we can't call put_task_struct
> > + * in atomic context because it will indirectly
> > + * acquire sleeping locks.
> > + */
> > + call_rcu(&tsk->rcu, __delayed_put_task_struct);
>
> Perhaps this deserves additional note to explain why is it safe to use tsk->rcu
> union. May be this is obvious, but I was confused when I looked at the previous
> version ;)
>
Makes sense, I will add it in the next version.
> but again, feel free to ignore.
>
> Oleg.
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v3] kernel/fork: beware of __put_task_struct calling context
2023-02-02 19:55 ` Wander Lairson Costa
@ 2023-02-02 20:22 ` Oleg Nesterov
0 siblings, 0 replies; 4+ messages in thread
From: Oleg Nesterov @ 2023-02-02 20:22 UTC (permalink / raw)
To: Wander Lairson Costa
Cc: Andrew Morton, Thomas Gleixner, Eric W. Biederman,
Andy Lutomirski, Sebastian Andrzej Siewior, Peter Zijlstra,
Liam R. Howlett, Fenghua Yu, Andrei Vagin, open list, Hu Chunyu,
Valentin Schneider, Paul McKenney
On 02/02, Wander Lairson Costa wrote:
>
> > We already have delayed_put_task_struct() which differs very much.
> > Perhaps something like ___put_task_struct() will look less confusing.
> >
>
> ___put_task_struct()? I already added a function with this name below.
Ah, I meant ___put_task_struct_rcu() or something like this. Bug again
this is just cosmetic nit, please ignore
> > > +void __put_task_struct(struct task_struct *tsk)
> > > +{
> > > + if (IS_ENABLED(CONFIG_PREEMPT_RT) && (!preemptible() || !in_task()))
> > > + /*
> > > + * under PREEMPT_RT, we can't call put_task_struct
> > > + * in atomic context because it will indirectly
> > > + * acquire sleeping locks.
> > > + */
> > > + call_rcu(&tsk->rcu, __delayed_put_task_struct);
> >
> > Perhaps this deserves additional note to explain why is it safe to use tsk->rcu
> > union. May be this is obvious, but I was confused when I looked at the previous
> > version ;)
> >
>
> Makes sense, I will add it in the next version.
Thanks ;)
Oleg.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-02-02 20:24 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-02-01 12:45 [PATCH v3] kernel/fork: beware of __put_task_struct calling context Wander Lairson Costa
2023-02-02 18:37 ` Oleg Nesterov
2023-02-02 19:55 ` Wander Lairson Costa
2023-02-02 20:22 ` Oleg Nesterov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox