From: Eric Biggers <ebiggers@kernel.org>
To: Ard Biesheuvel <ardb+git@google.com>
Cc: linux-efi@vger.kernel.org, x86@kernel.org,
Ard Biesheuvel <ardb@kernel.org>, Ivan Hu <ivan.hu@canonical.com>
Subject: Re: [PATCH] x86/efi: Restore IRQ state in EFI page fault handler
Date: Mon, 4 May 2026 11:01:07 -0700 [thread overview]
Message-ID: <20260504180107.GD2291@sol> (raw)
In-Reply-To: <20260501090311.2483809-2-ardb+git@google.com>
On Fri, May 01, 2026 at 11:03:12AM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
>
> The kernel's softirq API does not permit re-enabling softirqs while IRQs
> are disabled. The reason for this is that local_bh_enable() will not
> only re-enable delivery of softirqs over the back of IRQs, it will also
> handle any pending softirqs immediately, regardless of whether IRQs are
> enabled at that point.
>
> For this reason, commit
>
> d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs")
>
> disables softirqs only when IRQs are enabled, as it is not permitted
> otherwise, but also unnecessary, given that asynchronous softirq
> delivery never happens to begin with while IRQs are disabled.
>
> However, this does mean that entering a kernel mode FPU section with
> IRQs enabled and leaving it with IRQs disabled leads to problems, as
> identified by Sashiko [0]: the EFI page fault handler is called from
> page_fault_oops() with IRQs disabled, and thus ends the kernel mode FPU
> section with IRQs disabled as well, regardless of whether IRQs were
> enabled when it was started. This may result in schedule() being called
> with a non-zero preempt_count, causing a BUG().
>
> So take care to re-enable IRQs when handling any EFI page faults if they
> were taken with IRQs enabled.
>
> [0] https://sashiko.dev/#/patchset/20260430074107.27051-1-ivan.hu%40canonical.com
>
> Cc: Eric Biggers <ebiggers@kernel.org>
> Cc: Ivan Hu <ivan.hu@canonical.com>
> Fixes: d02198550423 ("x86/fpu: Improve crypto performance by making kernel-mode FPU reliably usable in softirqs")
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> arch/x86/include/asm/efi.h | 3 ++-
> arch/x86/mm/fault.c | 2 +-
> arch/x86/platform/efi/quirks.c | 11 ++++++++++-
> 3 files changed, 13 insertions(+), 3 deletions(-)
Reviewed-by: Eric Biggers <ebiggers@kernel.org>
- Eric
prev parent reply other threads:[~2026-05-04 18:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-01 9:03 [PATCH] x86/efi: Restore IRQ state in EFI page fault handler Ard Biesheuvel
2026-05-04 16:39 ` Ard Biesheuvel
2026-05-04 18:01 ` Eric Biggers [this message]
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=20260504180107.GD2291@sol \
--to=ebiggers@kernel.org \
--cc=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=ivan.hu@canonical.com \
--cc=linux-efi@vger.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: 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.