From: Ingo Molnar <mingo@kernel.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, linux-pm@vger.kernel.org,
Borislav Petkov <bp@alien8.de>,
Thomas Gleixner <tglx@linutronix.de>,
Ayush Jain <Ayush.Jain3@amd.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
Ard Biesheuvel <ardb@kernel.org>
Subject: Re: [PATCH] x86/fpu: Fix irq_fpu_usable() to return false during CPU onlining
Date: Mon, 19 May 2025 10:26:24 +0200 [thread overview]
Message-ID: <aCrrMEN01O7FWY6V@gmail.com> (raw)
In-Reply-To: <20250518193212.1822-1-ebiggers@kernel.org>
* Eric Biggers <ebiggers@kernel.org> wrote:
> --- a/arch/x86/kernel/fpu/core.c
> +++ b/arch/x86/kernel/fpu/core.c
> @@ -42,12 +42,15 @@ struct fpu_state_config fpu_user_cfg __ro_after_init;
> * Represents the initial FPU state. It's mostly (but not completely) zeroes,
> * depending on the FPU hardware format:
> */
> struct fpstate init_fpstate __ro_after_init;
>
> -/* Track in-kernel FPU usage */
> -static DEFINE_PER_CPU(bool, in_kernel_fpu);
> +/*
> + * Track FPU initialization and kernel-mode usage. 'true' means the FPU is
> + * initialized and is not currently being used by the kernel:
> + */
> +DEFINE_PER_CPU(bool, kernel_fpu_allowed);
So this is a nice independent cleanup, regardless of the CPU
bootstrapping bug it fixes. The fuzzy/negated meaning of in_kernel_fpu
always bothered me a bit, and your patch makes this condition a bit
cleaner, plus it defaults to 'disabled' on zero-initialization, which
is a bonus.
> void kernel_fpu_end(void)
> {
> - WARN_ON_FPU(!this_cpu_read(in_kernel_fpu));
> + /* Toggle kernel_fpu_allowed back to true: */
> + WARN_ON_FPU(this_cpu_read(kernel_fpu_allowed));
> + this_cpu_write(kernel_fpu_allowed, true);
>
> - this_cpu_write(in_kernel_fpu, false);
> if (!irqs_disabled())
> fpregs_unlock();
In addition to this fix, feel free to also send your x86 irqs-enabled
FPU model optimization series on top, Ard says it shouldn't cause
fundamental problems on EFI.
> }
> EXPORT_SYMBOL_GPL(kernel_fpu_end);
>
> diff --git a/arch/x86/kernel/fpu/init.c b/arch/x86/kernel/fpu/init.c
> index 6bb3e35c40e24..99db41bf9fa6b 100644
> --- a/arch/x86/kernel/fpu/init.c
> +++ b/arch/x86/kernel/fpu/init.c
> @@ -49,10 +49,13 @@ static void fpu__init_cpu_generic(void)
> */
> void fpu__init_cpu(void)
> {
> fpu__init_cpu_generic();
> fpu__init_cpu_xstate();
> +
> + /* Start allowing kernel-mode FPU: */
> + this_cpu_write(kernel_fpu_allowed, true);
Since this goes outside the regular kernel_fpu_begin()/end() methods,
could you please also add an WARN_ON_FPU() check to make sure it was
false before? x86 CPU init code is still a bit of spaghetti at times.
> @@ -1186,10 +1186,16 @@ void cpu_disable_common(void)
> {
> int cpu = smp_processor_id();
>
> remove_siblinginfo(cpu);
>
> + /*
> + * Stop allowing kernel-mode FPU. This is needed so that if the CPU is
> + * brought online again, the initial state is not allowed:
> + */
> + this_cpu_write(kernel_fpu_allowed, false);
Ditto, an WARN_ON_FPU() would be nice: if kernel FPU is disabled at
this point then something's fishy.
Thanks,
Ingo
next prev parent reply other threads:[~2025-05-19 8:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-18 19:32 [PATCH] x86/fpu: Fix irq_fpu_usable() to return false during CPU onlining Eric Biggers
2025-05-19 4:18 ` Jain, Ayush
2025-05-19 8:26 ` Ingo Molnar [this message]
2025-05-19 8:32 ` Ingo Molnar
2025-05-19 17:04 ` Eric Biggers
2025-05-20 9:33 ` Ingo Molnar
2025-05-21 15:39 ` Thomas Gleixner
2025-05-24 2:55 ` Eric Biggers
2025-05-21 15:39 ` Thomas Gleixner
2025-05-26 2:56 ` Herbert Xu
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=aCrrMEN01O7FWY6V@gmail.com \
--to=mingo@kernel.org \
--cc=Ayush.Jain3@amd.com \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=tglx@linutronix.de \
--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: link
Be 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.