From: Frederic Weisbecker <frederic@kernel.org>
To: Boqun Feng <boqun.feng@gmail.com>
Cc: linux-kernel@vger.kernel.org, rcu@vger.kernel.org,
Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
Chen Zhongjin <chenzhongjin@huawei.com>,
Yang Jihong <yangjihong1@huawei.com>,
Neeraj Upadhyay <quic_neeraju@quicinc.com>,
Joel Fernandes <joel@joelfernandes.org>,
Josh Triplett <josh@joshtriplett.org>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Zqiang <qiang.zhang1211@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Kent Overstreet <kent.overstreet@linux.dev>,
Oleg Nesterov <oleg@redhat.com>,
Heiko Carstens <hca@linux.ibm.com>,
Christian Brauner <brauner@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
Mike Christie <michael.christie@oracle.com>,
Mateusz Guzik <mjguzik@gmail.com>,
Nicholas Piggin <npiggin@gmail.com>,
Peng Zhang <zhangpeng.00@bytedance.com>
Subject: Re: [PATCH v2 3/6] rcu-tasks: Initialize data to eliminate RCU-tasks/do_exit() deadlocks
Date: Thu, 22 Feb 2024 17:21:03 +0100 [thread overview]
Message-ID: <Zdd0b3HI4uNAoc2P@localhost.localdomain> (raw)
In-Reply-To: <20240217012745.3446231-4-boqun.feng@gmail.com>
Le Fri, Feb 16, 2024 at 05:27:38PM -0800, Boqun Feng a écrit :
> From: "Paul E. McKenney" <paulmck@kernel.org>
>
> Holding a mutex across synchronize_rcu_tasks() and acquiring
> that same mutex in code called from do_exit() after its call to
> exit_tasks_rcu_start() but before its call to exit_tasks_rcu_stop()
> results in deadlock. This is by design, because tasks that are far
> enough into do_exit() are no longer present on the tasks list, making
> it a bit difficult for RCU Tasks to find them, let alone wait on them
> to do a voluntary context switch. However, such deadlocks are becoming
> more frequent. In addition, lockdep currently does not detect such
> deadlocks and they can be difficult to reproduce.
>
> In addition, if a task voluntarily context switches during that time
> (for example, if it blocks acquiring a mutex), then this task is in an
> RCU Tasks quiescent state. And with some adjustments, RCU Tasks could
> just as well take advantage of that fact.
>
> This commit therefore initializes the data structures that will be needed
> to rely on these quiescent states and to eliminate these deadlocks.
>
> Link: https://lore.kernel.org/all/20240118021842.290665-1-chenzhongjin@huawei.com/
>
> Reported-by: Chen Zhongjin <chenzhongjin@huawei.com>
> Reported-by: Yang Jihong <yangjihong1@huawei.com>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> Tested-by: Yang Jihong <yangjihong1@huawei.com>
> Tested-by: Chen Zhongjin <chenzhongjin@huawei.com>
> Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
> ---
> init/init_task.c | 1 +
> kernel/fork.c | 1 +
> kernel/rcu/tasks.h | 2 ++
> 3 files changed, 4 insertions(+)
>
> diff --git a/init/init_task.c b/init/init_task.c
> index 7ecb458eb3da..4daee6d761c8 100644
> --- a/init/init_task.c
> +++ b/init/init_task.c
> @@ -147,6 +147,7 @@ struct task_struct init_task __aligned(L1_CACHE_BYTES) = {
> .rcu_tasks_holdout = false,
> .rcu_tasks_holdout_list = LIST_HEAD_INIT(init_task.rcu_tasks_holdout_list),
> .rcu_tasks_idle_cpu = -1,
> + .rcu_tasks_exit_list = LIST_HEAD_INIT(init_task.rcu_tasks_exit_list),
> #endif
> #ifdef CONFIG_TASKS_TRACE_RCU
> .trc_reader_nesting = 0,
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 0d944e92a43f..af7203be1d2d 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1976,6 +1976,7 @@ static inline void rcu_copy_process(struct task_struct *p)
> p->rcu_tasks_holdout = false;
> INIT_LIST_HEAD(&p->rcu_tasks_holdout_list);
> p->rcu_tasks_idle_cpu = -1;
> + INIT_LIST_HEAD(&p->rcu_tasks_exit_list);
> #endif /* #ifdef CONFIG_TASKS_RCU */
> #ifdef CONFIG_TASKS_TRACE_RCU
> p->trc_reader_nesting = 0;
> diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
> index b7d5f2757053..4a5d562e3189 100644
> --- a/kernel/rcu/tasks.h
> +++ b/kernel/rcu/tasks.h
> @@ -277,6 +277,8 @@ static void cblist_init_generic(struct rcu_tasks *rtp)
> rtpcp->rtpp = rtp;
> if (!rtpcp->rtp_blkd_tasks.next)
> INIT_LIST_HEAD(&rtpcp->rtp_blkd_tasks);
> + if (!rtpcp->rtp_exit_list.next)
I assume there can't be an exiting task concurrently at this point on
boot. Because kthreadd just got created and workqueues as well but that's it,
right? Or workqueues can die that early? Probably not.
> + INIT_LIST_HEAD(&rtpcp->rtp_exit_list);
Because if tasks can exit concurrently, then we are in trouble :-)
Thanks.
> }
>
> pr_info("%s: Setting shift to %d and lim to %d rcu_task_cb_adjust=%d.\n", rtp->name,
> --
> 2.43.0
>
next prev parent reply other threads:[~2024-02-22 16:21 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-17 1:27 [PATCH v2 0/6] RCU tasks fixes for v6.9 Boqun Feng
2024-02-17 1:27 ` [PATCH v2 1/6] rcu-tasks: Repair RCU Tasks Trace quiescence check Boqun Feng
2024-02-17 1:27 ` [PATCH v2 2/6] rcu-tasks: Add data to eliminate RCU-tasks/do_exit() deadlocks Boqun Feng
2024-02-22 16:54 ` Frederic Weisbecker
2024-02-22 20:46 ` Paul E. McKenney
2024-02-17 1:27 ` [PATCH v2 3/6] rcu-tasks: Initialize " Boqun Feng
2024-02-22 16:21 ` Frederic Weisbecker [this message]
2024-02-22 20:41 ` Paul E. McKenney
2024-02-23 11:39 ` Frederic Weisbecker
2024-02-17 1:27 ` [PATCH v2 4/6] rcu-tasks: Maintain lists " Boqun Feng
2024-02-22 16:32 ` Frederic Weisbecker
2024-02-23 12:19 ` Frederic Weisbecker
2024-02-24 0:28 ` Paul E. McKenney
2024-02-17 1:27 ` [PATCH v2 5/6] rcu-tasks: Eliminate deadlocks involving do_exit() and RCU tasks Boqun Feng
2024-02-22 16:46 ` Frederic Weisbecker
2024-02-17 1:27 ` [PATCH v2 6/6] rcu-tasks: Maintain real-time response in rcu_tasks_postscan() Boqun Feng
2024-02-22 17:48 ` Frederic Weisbecker
2024-02-22 20:52 ` Paul E. McKenney
2024-02-22 22:56 ` Paul E. McKenney
2024-02-23 12:17 ` Frederic Weisbecker
2024-02-23 15:14 ` Frederic Weisbecker
2024-02-24 0:23 ` Paul E. McKenney
2024-02-22 16:52 ` [PATCH v2 0/6] RCU tasks fixes for v6.9 Frederic Weisbecker
2024-02-22 22:09 ` Paul E. McKenney
2024-02-23 12:25 ` Frederic Weisbecker
2024-02-24 0:43 ` Paul E. McKenney
2024-02-26 13:56 ` Frederic Weisbecker
2024-02-26 14:37 ` Paul E. McKenney
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=Zdd0b3HI4uNAoc2P@localhost.localdomain \
--to=frederic@kernel.org \
--cc=Neeraj.Upadhyay@amd.com \
--cc=akpm@linux-foundation.org \
--cc=boqun.feng@gmail.com \
--cc=brauner@kernel.org \
--cc=chenzhongjin@huawei.com \
--cc=hca@linux.ibm.com \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=kent.overstreet@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=michael.christie@oracle.com \
--cc=mjguzik@gmail.com \
--cc=mst@redhat.com \
--cc=npiggin@gmail.com \
--cc=oleg@redhat.com \
--cc=paulmck@kernel.org \
--cc=qiang.zhang1211@gmail.com \
--cc=quic_neeraju@quicinc.com \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=surenb@google.com \
--cc=yangjihong1@huawei.com \
--cc=zhangpeng.00@bytedance.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox