From: Timothy Pearson <tpearson@raptorengineering.com>
To: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: [PATCH] powerpc: Fix data corruption on IPI
Date: Tue, 14 Nov 2023 02:00:27 -0600 (CST) [thread overview]
Message-ID: <1654757454.47202735.1699948827325.JavaMail.zimbra@raptorengineeringinc.com> (raw)
From 0b2678b7cdada1a3d9aec8626f31a988d81373fa Mon Sep 17 00:00:00 2001
From: Timothy Pearson <tpearson@raptorengineering.com>
Date: Mon, 13 Nov 2023 22:42:58 -0600
Subject: [PATCH] powerpc: Fix data corruption on IPI
On multithreaded SMP workloads such as those using io_uring, it is possible for
multiple threads to hold an inconsistent view of system memory when an IPI is
issued. This in turn leads to userspace memory corruption with varying degrees
of probability based on workload and inter-thread timing.
io_uring provokes this bug by its use of TWA_SIGNAL during thread creation,
which is especially noticeable as significant userspace data corruption with
certain workloads such as MariaDB (bug MDEV-30728). While using
TWA_SIGNAL_NO_IPI works around the corruption, no other architecture requires
this workaround.
Issue an lwsync barrier instruction prior to sending the IPI. This ensures
the receiving CPU has a consistent view of system memory, in line with other
architectures.
Tested under QEMU in kvm mode, running on a Talos II workstation with dual
POWER9 DD2.2 CPUs.
Tested-by: Timothy Pearson <tpearson@raptorengineering.com>
Signed-off-by: Timothy Pearson <tpearson@raptorengineering.com>
---
arch/powerpc/kernel/smp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index ab691c89d787..ba42238de518 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -369,8 +369,10 @@ static inline void do_message_pass(int cpu, int msg)
void arch_smp_send_reschedule(int cpu)
{
- if (likely(smp_ops))
+ if (likely(smp_ops)) {
+ __smp_lwsync();
do_message_pass(cpu, PPC_MSG_RESCHEDULE);
+ }
}
EXPORT_SYMBOL_GPL(arch_smp_send_reschedule);
--
2.39.2
next reply other threads:[~2023-11-14 8:07 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-14 8:00 Timothy Pearson [this message]
2023-11-14 12:14 ` [PATCH] powerpc: Fix data corruption on IPI Michael Ellerman
2023-11-14 21:32 ` Timothy Pearson
2023-11-15 3:11 ` Nicholas Piggin
2023-11-17 7:39 ` Timothy Pearson
2023-11-17 7:52 ` Timothy Pearson
2023-11-17 8:01 ` Nicholas Piggin
2023-11-17 8:20 ` Timothy Pearson
2023-11-17 8:26 ` Timothy Pearson
2023-11-17 8:54 ` Timothy Pearson
[not found] <19221908.47168775.1699937769845.JavaMail.zimbra@raptorengineeringinc.com>
[not found] ` <ZVMo0vOZAxuxT8la@eldamar.lan>
2023-11-14 8:03 ` Timothy Pearson
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=1654757454.47202735.1699948827325.JavaMail.zimbra@raptorengineeringinc.com \
--to=tpearson@raptorengineering.com \
--cc=linuxppc-dev@lists.ozlabs.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