From: Wander Lairson Costa <wander@redhat.com>
To: Oleg Nesterov <oleg@redhat.com>,
"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>,
Brian Cain <bcain@quicinc.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Stafford Horne <shorne@gmail.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
Wander Lairson Costa <wander@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <Liam.Howlett@Oracle.com>,
Vlastimil Babka <vbabka@suse.cz>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
Andrei Vagin <avagin@gmail.com>,
Peter Zijlstra <peterz@infradead.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
Daniel Bristot de Oliveira <bristot@kernel.org>,
Yu Zhao <yuzhao@google.com>, Alexey Gladkov <legion@kernel.org>,
Mike Kravetz <mike.kravetz@oracle.com>,
Yang Shi <shy828301@gmail.com>,
linux-kernel@vger.kernel.org (open list)
Cc: Hu Chunyu <chuhu@redhat.com>,
Valentin Schneider <vschneid@redhat.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Steven Rostedt <rostedt@goodmis.org>,
Luis Goncalves <lgoncalv@redhat.com>
Subject: [PATCH v9] kernel/fork: beware of __put_task_struct calling context
Date: Tue, 16 May 2023 16:14:41 -0300 [thread overview]
Message-ID: <20230516191441.34377-1-wander@redhat.com> (raw)
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.
Changelog
=========
v1:
* Initial implementation fixing the splat.
v2:
* Isolate the logic in its own function.
* Fix two more cases caught in review.
v3:
* Change __put_task_struct() to handle the issue internally.
v4:
* Explain why call_rcu() is safe to call from interrupt context.
v5:
* Explain why __put_task_struct() doesn't conflict with
put_task_sruct_rcu_user.
v6:
* As per Sebastian's review, revert back the implementation of v2
with a distinct function.
* Add a check in put_task_struct() to warning when called from a
non-sleepable context.
* Address more call sites.
v7:
* Fix typos.
* Add an explanation why the new function doesn't conflict with
delayed_free_task().
v8:
* Bring back v5.
* Fix coding style.
v9:
* Reorganize to not need ___put_task_struct() by Oleg's suggestion.
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>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Paul McKenney <paulmck@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Luis Goncalves <lgoncalv@redhat.com>
---
include/linux/sched/task.h | 28 +++++++++++++++++++++++++++-
kernel/fork.c | 8 ++++++++
2 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h
index d6c48163c6de..9bcb9535d4e1 100644
--- a/include/linux/sched/task.h
+++ b/include/linux/sched/task.h
@@ -112,10 +112,36 @@ static inline struct task_struct *get_task_struct(struct task_struct *t)
}
extern void __put_task_struct(struct task_struct *t);
+extern void __put_task_struct_rcu_cb(struct rcu_head *rhp);
static inline void put_task_struct(struct task_struct *t)
{
- if (refcount_dec_and_test(&t->usage))
+ if (!refcount_dec_and_test(&t->usage))
+ return;
+
+ /*
+ * under PREEMPT_RT, we can't call put_task_struct
+ * in atomic context because it will indirectly
+ * acquire sleeping locks.
+ *
+ * call_rcu() will schedule delayed_put_task_struct_rcu()
+ * to be called in process context.
+ *
+ * __put_task_struct() is called when
+ * refcount_dec_and_test(&t->usage) succeeds.
+ *
+ * This means that it can't "conflict" with
+ * put_task_struct_rcu_user() which abuses ->rcu the same
+ * way; rcu_users has a reference so task->usage can't be
+ * zero after rcu_users 1 -> 0 transition.
+ *
+ * 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().
+ */
+ if (IS_ENABLED(CONFIG_PREEMPT_RT) && !preemptible())
+ call_rcu(&t->rcu, __put_task_struct_rcu_cb);
+ else
__put_task_struct(t);
}
diff --git a/kernel/fork.c b/kernel/fork.c
index 08969f5aa38d..fd3bb4a554c4 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -846,6 +846,14 @@ void __put_task_struct(struct task_struct *tsk)
}
EXPORT_SYMBOL_GPL(__put_task_struct);
+void __put_task_struct_rcu_cb(struct rcu_head *rhp)
+{
+ struct task_struct *task = container_of(rhp, struct task_struct, rcu);
+
+ __put_task_struct(task);
+}
+EXPORT_SYMBOL_GPL(__put_task_struct_rcu_cb);
+
void __init __weak arch_task_cache_init(void) { }
/*
--
2.40.1
next reply other threads:[~2023-05-16 19:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-16 19:14 Wander Lairson Costa [this message]
2023-05-16 19:24 ` [PATCH v9] kernel/fork: beware of __put_task_struct calling context Matthew Wilcox
2023-05-16 21:05 ` Andrew Morton
2023-05-16 21:41 ` Matthew Wilcox
2023-05-16 22:50 ` Andrew Morton
2023-05-17 15:26 ` Oleg Nesterov
2023-05-17 16:57 ` Wander Lairson Costa
2023-05-29 12:22 ` Oleg Nesterov
2023-06-01 17:45 ` Wander Lairson Costa
2023-06-01 18:13 ` Oleg Nesterov
2023-06-01 18:23 ` Wander Lairson Costa
2023-06-02 17:34 ` Oleg Nesterov
2023-06-05 11:24 ` Wander Lairson Costa
2023-06-06 20:39 ` Oleg Nesterov
2023-06-09 19:07 ` Wander Lairson Costa
2023-06-02 17:39 ` Oleg Nesterov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230516191441.34377-1-wander@redhat.com \
--to=wander@redhat.com \
--cc=Liam.Howlett@Oracle.com \
--cc=akpm@linux-foundation.org \
--cc=avagin@gmail.com \
--cc=bcain@quicinc.com \
--cc=bigeasy@linutronix.de \
--cc=bristot@kernel.org \
--cc=chuhu@redhat.com \
--cc=ebiederm@xmission.com \
--cc=legion@kernel.org \
--cc=lgoncalv@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mike.kravetz@oracle.com \
--cc=mpe@ellerman.id.au \
--cc=oleg@redhat.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rmk+kernel@armlinux.org.uk \
--cc=rostedt@goodmis.org \
--cc=shorne@gmail.com \
--cc=shy828301@gmail.com \
--cc=vbabka@suse.cz \
--cc=vschneid@redhat.com \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
--cc=yuzhao@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.