linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Pavel Pisa <pisa@cmp.felk.cvut.cz>,
	linux-rt-users@vger.kernel.org,
	Pavel Hronek <hronepa1@fel.cvut.cz>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: [PATCH 1/3] ARM: vfp: Provide vfp_lock() for VFP locking.
Date: Fri, 19 May 2023 16:57:29 +0200	[thread overview]
Message-ID: <20230519145731.574867-2-bigeasy@linutronix.de> (raw)
In-Reply-To: <20230519145731.574867-1-bigeasy@linutronix.de>

kernel_neon_begin() uses local_bh_disable() to ensure exclusive access
to the VFP unit. This is broken on PREEMPT_RT because a BH disabled
section remains preemptible on PREEMPT_RT.

Introduce vfp_lock() which uses local_bh_disable() and preempt_disable()
on PREEMPT_RT. Since softirqs are processed always in thread context,
disabling preemption is enough to ensure that the current context won't
get interrupted by something that is using the VFP. Use it in
kernel_neon_begin().

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 arch/arm/vfp/vfpmodule.c | 32 ++++++++++++++++++++++++++++++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 349dcb944a937..57f9527d1e50e 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -54,6 +54,34 @@ static unsigned int __initdata VFP_arch;
  */
 union vfp_state *vfp_current_hw_state[NR_CPUS];
 
+/*
+ * Claim ownership of the VFP unit.
+ *
+ * The caller may change VFP registers until vfp_unlock() is called.
+ *
+ * local_bh_disable() is used to disable preemption and to disable VFP
+ * processing in softirq context. On PREEMPT_RT kernels local_bh_disable() is
+ * not sufficient because it only serializes soft interrupt related sections
+ * via a local lock, but stays preemptible. Disabling preemption is the right
+ * choice here as bottom half processing is always in thread context on RT
+ * kernels so it implicitly prevents bottom half processing as well.
+ */
+static void vfp_lock(void)
+{
+	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+		local_bh_disable();
+	else
+		preempt_disable();
+}
+
+static void vfp_unlock(void)
+{
+	if (!IS_ENABLED(CONFIG_PREEMPT_RT))
+		local_bh_enable();
+	else
+		preempt_enable();
+}
+
 /*
  * Is 'thread's most up to date state stored in this CPUs hardware?
  * Must be called from non-preemptible context.
@@ -738,7 +766,7 @@ void kernel_neon_begin(void)
 	unsigned int cpu;
 	u32 fpexc;
 
-	local_bh_disable();
+	vfp_lock();
 
 	/*
 	 * Kernel mode NEON is only allowed outside of hardirq context with
@@ -769,7 +797,7 @@ void kernel_neon_end(void)
 {
 	/* Disable the NEON/VFP unit. */
 	fmxr(FPEXC, fmrx(FPEXC) & ~FPEXC_EN);
-	local_bh_enable();
+	vfp_unlock();
 }
 EXPORT_SYMBOL(kernel_neon_end);
 
-- 
2.40.1


  reply	other threads:[~2023-05-19 14:57 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <202305142217.46875.pisa@cmp.felk.cvut.cz>
2023-05-16 16:33 ` Preemp-RT kernel builds from 6.3 on fails on Xilinx Zynq 7Z010 Sebastian Andrzej Siewior
2023-05-16 17:13   ` Ard Biesheuvel
2023-05-17  8:54     ` Sebastian Andrzej Siewior
2023-05-17 11:05       ` Ard Biesheuvel
2023-05-17 14:37         ` Sebastian Andrzej Siewior
2023-05-17 22:05           ` Ard Biesheuvel
2023-05-19 14:57             ` [PATCH 0/3] ARM: vfp: Fixes for PREEMP_RT Sebastian Andrzej Siewior
2023-05-19 14:57               ` Sebastian Andrzej Siewior [this message]
2023-05-19 14:57               ` [PATCH 2/3] ARM: vfp: Use vfp_lock() in vfp_sync_hwstate() Sebastian Andrzej Siewior
2023-05-19 14:57               ` [PATCH 3/3] ARM: vfp: Use vfp_lock() in vfp_entry() Sebastian Andrzej Siewior
2023-05-19 16:14               ` [PATCH 0/3] ARM: vfp: Fixes for PREEMP_RT Ard Biesheuvel
2023-05-19 18:06                 ` Sebastian Andrzej Siewior
2023-05-19 19:42                   ` Ard Biesheuvel
2023-05-19 18:52 ` Preemp-RT kernel builds from 6.3 on fails on Xilinx Zynq 7Z010 Sebastian Andrzej Siewior
2023-05-21 14:57   ` Pavel Pisa
2023-05-22  7:44     ` Sebastian Andrzej Siewior

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=20230519145731.574867-2-bigeasy@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=ardb@kernel.org \
    --cc=hronepa1@fel.cvut.cz \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=pisa@cmp.felk.cvut.cz \
    --cc=tglx@linutronix.de \
    /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).