From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: stable@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
patches@lists.linux.dev, "Paul E. McKenney" <paulmck@kernel.org>,
Joel Fernandes <joel@joelfernandes.org>
Subject: [PATCH 5.15 8/9] rcu-tasks: Wait for trc_read_check_handler() IPIs
Date: Thu, 31 Aug 2023 13:10:16 +0200 [thread overview]
Message-ID: <20230831110830.405228681@linuxfoundation.org> (raw)
In-Reply-To: <20230831110830.039135096@linuxfoundation.org>
5.15-stable review patch. If anyone has any objections, please let me know.
------------------
From: Paul E. McKenney <paulmck@kernel.org>
commit cbe0d8d91415c9692fe88191940d98952b6855d9 upstream.
Currently, RCU Tasks Trace initializes the trc_n_readers_need_end counter
to the value one, increments it before each trc_read_check_handler()
IPI, then decrements it within trc_read_check_handler() if the target
task was in a quiescent state (or if the target task moved to some other
CPU while the IPI was in flight), complaining if the new value was zero.
The rationale for complaining is that the initial value of one must be
decremented away before zero can be reached, and this decrement has not
yet happened.
Except that trc_read_check_handler() is initiated with an asynchronous
smp_call_function_single(), which might be significantly delayed. This
can result in false-positive complaints about the counter reaching zero.
This commit therefore waits for in-flight IPI handlers to complete before
decrementing away the initial value of one from the trc_n_readers_need_end
counter.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Joel Fernandes <joel@joelfernandes.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/rcu/tasks.h | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--- a/kernel/rcu/tasks.h
+++ b/kernel/rcu/tasks.h
@@ -1166,14 +1166,28 @@ static void check_all_holdout_tasks_trac
}
}
+static void rcu_tasks_trace_empty_fn(void *unused)
+{
+}
+
/* Wait for grace period to complete and provide ordering. */
static void rcu_tasks_trace_postgp(struct rcu_tasks *rtp)
{
+ int cpu;
bool firstreport;
struct task_struct *g, *t;
LIST_HEAD(holdouts);
long ret;
+ // Wait for any lingering IPI handlers to complete. Note that
+ // if a CPU has gone offline or transitioned to userspace in the
+ // meantime, all IPI handlers should have been drained beforehand.
+ // Yes, this assumes that CPUs process IPIs in order. If that ever
+ // changes, there will need to be a recheck and/or timed wait.
+ for_each_online_cpu(cpu)
+ if (smp_load_acquire(per_cpu_ptr(&trc_ipi_to_cpu, cpu)))
+ smp_call_function_single(cpu, rcu_tasks_trace_empty_fn, NULL, 1);
+
// Remove the safety count.
smp_mb__before_atomic(); // Order vs. earlier atomics
atomic_dec(&trc_n_readers_need_end);
next prev parent reply other threads:[~2023-08-31 11:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-31 11:10 [PATCH 5.15 0/9] 5.15.130-rc1 review Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.15 1/9] ACPI: thermal: Drop nocrt parameter Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.15 2/9] module: Expose module_init_layout_section() Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.15 3/9] arm64: module-plts: inline linux/moduleloader.h Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.15 4/9] arm64: module: Use module_init_layout_section() to spot init sections Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.15 5/9] ARM: " Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.15 6/9] rcu: Prevent expedited GP from enabling tick on offline CPU Greg Kroah-Hartman
2023-08-31 11:10 ` [PATCH 5.15 7/9] rcu-tasks: Fix IPI failure handling in trc_wait_for_one_reader Greg Kroah-Hartman
2023-08-31 11:10 ` Greg Kroah-Hartman [this message]
2023-08-31 11:10 ` [PATCH 5.15 9/9] rcu-tasks: Add trc_inspect_reader() checks for exiting critical section Greg Kroah-Hartman
2023-08-31 20:43 ` [PATCH 5.15 0/9] 5.15.130-rc1 review Florian Fainelli
2023-09-01 1:01 ` SeongJae Park
2023-09-01 6:23 ` Ron Economos
2023-09-01 9:39 ` Sudip Mukherjee (Codethink)
2023-09-01 11:03 ` Naresh Kamboju
2023-09-01 15:35 ` Shuah Khan
2023-09-01 18:44 ` Jon Hunter
2023-09-02 4:20 ` Guenter Roeck
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=20230831110830.405228681@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=joel@joelfernandes.org \
--cc=patches@lists.linux.dev \
--cc=paulmck@kernel.org \
--cc=stable@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).