All of lore.kernel.org
 help / color / mirror / Atom feed
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 3/3] x86/fpu: Don't support kernel-mode FPU when irqs_disabled()
Date: Sun, 18 May 2025 08:34:25 +0200	[thread overview]
Message-ID: <aCl_cSO2XqtSQEZT@gmail.com> (raw)
In-Reply-To: <20250517183919.GC1239@sol>


* Eric Biggers <ebiggers@kernel.org> wrote:

> > Alternatively we could set in_kernel_fpu during CPU bootstrap, and 
> > clear it once we know the FPU is usable? This is only a relatively 
> > short early boot period, with no scheduling, right?
> 
> Yes, if there isn't agreement on this approach we can do that 
> instead.  Say:
> 
> - Replace in_kernel_fpu with kernel_fpu_supported, with the opposite 
>   meaning (so that the initial value of false means "unsupported")

I'm not against simplifying the x86 FPU model to exclude IRQs-off
context (especially if it also micro-optimizes some of the key runtime
kernel-FPU primitives), but it has to be a full solution and we'll have
to see how complicated the EFI changes get.

Ie. without seeing the full cost-benefit balance it's hard to call this
in advance. Mind sending a full series that addresses the EFI case too?

Thanks,

	Ingo

  reply	other threads:[~2025-05-18  6:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-16 23:18 [PATCH 0/3] x86: Don't support kernel-mode FPU with hardirqs disabled Eric Biggers
2025-05-16 23:18 ` [PATCH 1/3] x86/fpu: Add fpu_save_state() for __save_processor_state() Eric Biggers
2025-05-16 23:18 ` [PATCH 2/3] x86/pm: Use fpu_save_state() in __save_processor_state() Eric Biggers
2025-05-16 23:18 ` [PATCH 3/3] x86/fpu: Don't support kernel-mode FPU when irqs_disabled() Eric Biggers
2025-05-17  7:09   ` Ingo Molnar
2025-05-17 18:39     ` Eric Biggers
2025-05-18  6:34       ` Ingo Molnar [this message]
2025-05-18 13:18         ` Ard Biesheuvel
2025-05-18 20:01           ` Eric Biggers
2025-05-19  8:05             ` Ingo Molnar
2025-05-19  9:49               ` Ard Biesheuvel
2025-05-19 12:57                 ` Ingo Molnar
2025-05-19 13:50                   ` Ard Biesheuvel
2025-05-20  7:42                     ` Ingo Molnar
2025-05-17  1:30 ` [PATCH 0/3] x86: Don't support kernel-mode FPU with hardirqs disabled Eric Biggers

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=aCl_cSO2XqtSQEZT@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.