From: Valentin Schneider <valentin.schneider@arm.com> To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rt-users@vger.kernel.org, x86@kernel.org Cc: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Steven Rostedt <rostedt@goodmis.org>, Daniel Bristot de Oliveira <bristot@redhat.com>, "Peter Zijlstra (Intel)" <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>, Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>, Mark Brown <broonie@kernel.org>, Dave Martin <Dave.Martin@arm.com>, Ard Biesheuvel <ardb@kernel.org> Subject: [PATCH 2/3] x86/fpu: Make FPU protection reuse common helper Date: Thu, 22 Jul 2021 18:51:56 +0100 [thread overview] Message-ID: <20210722175157.1367122-3-valentin.schneider@arm.com> (raw) In-Reply-To: <20210722175157.1367122-1-valentin.schneider@arm.com> The newly-introduced preempt_{enable, disable}_bh() helpers are an exact stand-in for fpregs_{lock, unlock}(). Use them there. No change in behaviour intended. Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> --- arch/x86/include/asm/fpu/api.h | 19 ++----------------- 1 file changed, 2 insertions(+), 17 deletions(-) diff --git a/arch/x86/include/asm/fpu/api.h b/arch/x86/include/asm/fpu/api.h index 62cf3e4c06fb..ffebb9316bfd 100644 --- a/arch/x86/include/asm/fpu/api.h +++ b/arch/x86/include/asm/fpu/api.h @@ -54,31 +54,16 @@ static inline void kernel_fpu_begin(void) * fpu->state and set TIF_NEED_FPU_LOAD leaving CPU's FPU registers in * a random state. * - * local_bh_disable() protects against both preemption and soft interrupts - * on !RT kernels. - * - * On 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. - * * Disabling preemption also serializes against kernel_fpu_begin(). */ static inline void fpregs_lock(void) { - if (!IS_ENABLED(CONFIG_PREEMPT_RT)) - local_bh_disable(); - else - preempt_disable(); + preempt_disable_bh(); } static inline void fpregs_unlock(void) { - if (!IS_ENABLED(CONFIG_PREEMPT_RT)) - local_bh_enable(); - else - preempt_enable(); + preempt_enable_bh(); } #ifdef CONFIG_X86_DEBUG_FPU -- 2.25.1
WARNING: multiple messages have this Message-ID (diff)
From: Valentin Schneider <valentin.schneider@arm.com> To: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rt-users@vger.kernel.org, x86@kernel.org Cc: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Steven Rostedt <rostedt@goodmis.org>, Daniel Bristot de Oliveira <bristot@redhat.com>, "Peter Zijlstra (Intel)" <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>, Borislav Petkov <bp@alien8.de>, "H. Peter Anvin" <hpa@zytor.com>, Mark Brown <broonie@kernel.org>, Dave Martin <Dave.Martin@arm.com>, Ard Biesheuvel <ardb@kernel.org> Subject: [PATCH 2/3] x86/fpu: Make FPU protection reuse common helper Date: Thu, 22 Jul 2021 18:51:56 +0100 [thread overview] Message-ID: <20210722175157.1367122-3-valentin.schneider@arm.com> (raw) In-Reply-To: <20210722175157.1367122-1-valentin.schneider@arm.com> The newly-introduced preempt_{enable, disable}_bh() helpers are an exact stand-in for fpregs_{lock, unlock}(). Use them there. No change in behaviour intended. Signed-off-by: Valentin Schneider <valentin.schneider@arm.com> --- arch/x86/include/asm/fpu/api.h | 19 ++----------------- 1 file changed, 2 insertions(+), 17 deletions(-) diff --git a/arch/x86/include/asm/fpu/api.h b/arch/x86/include/asm/fpu/api.h index 62cf3e4c06fb..ffebb9316bfd 100644 --- a/arch/x86/include/asm/fpu/api.h +++ b/arch/x86/include/asm/fpu/api.h @@ -54,31 +54,16 @@ static inline void kernel_fpu_begin(void) * fpu->state and set TIF_NEED_FPU_LOAD leaving CPU's FPU registers in * a random state. * - * local_bh_disable() protects against both preemption and soft interrupts - * on !RT kernels. - * - * On 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. - * * Disabling preemption also serializes against kernel_fpu_begin(). */ static inline void fpregs_lock(void) { - if (!IS_ENABLED(CONFIG_PREEMPT_RT)) - local_bh_disable(); - else - preempt_disable(); + preempt_disable_bh(); } static inline void fpregs_unlock(void) { - if (!IS_ENABLED(CONFIG_PREEMPT_RT)) - local_bh_enable(); - else - preempt_enable(); + preempt_enable_bh(); } #ifdef CONFIG_X86_DEBUG_FPU -- 2.25.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-07-22 17:53 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-07-22 17:51 [PATCH 0/3] sched, x86, arm64: PREEMPT_RT, FPU and preemption Valentin Schneider 2021-07-22 17:51 ` Valentin Schneider 2021-07-22 17:51 ` [PATCH 1/3] sched/preempt: Introduce preempt_{enable, disable}_bh() Valentin Schneider 2021-07-22 17:51 ` Valentin Schneider 2021-07-22 17:51 ` Valentin Schneider [this message] 2021-07-22 17:51 ` [PATCH 2/3] x86/fpu: Make FPU protection reuse common helper Valentin Schneider 2021-07-22 17:51 ` [PATCH 3/3] arm64/fpsimd: Fix FPSIMD context handling vs PREEMPT_RT Valentin Schneider 2021-07-22 17:51 ` Valentin Schneider 2021-07-22 18:32 ` Mark Brown 2021-07-22 18:32 ` Mark Brown 2021-07-23 11:07 ` Valentin Schneider 2021-07-23 11:07 ` Valentin Schneider 2021-07-22 20:11 ` [PATCH 0/3] sched, x86, arm64: PREEMPT_RT, FPU and preemption Andrew Halaney 2021-07-22 20:11 ` Andrew Halaney 2021-07-23 14:12 ` Ard Biesheuvel 2021-07-23 14:12 ` Ard Biesheuvel
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=20210722175157.1367122-3-valentin.schneider@arm.com \ --to=valentin.schneider@arm.com \ --cc=Dave.Martin@arm.com \ --cc=ardb@kernel.org \ --cc=bp@alien8.de \ --cc=bristot@redhat.com \ --cc=broonie@kernel.org \ --cc=catalin.marinas@arm.com \ --cc=hpa@zytor.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-rt-users@vger.kernel.org \ --cc=mingo@kernel.org \ --cc=peterz@infradead.org \ --cc=rostedt@goodmis.org \ --cc=tglx@linutronix.de \ --cc=will@kernel.org \ --cc=x86@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: linkBe 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.