Thread (22 messages) 22 messages, 4 authors, 2025-09-22

Re: [PATCH v3 6/8] arm64/efi: Use a mutex to protect the EFI stack and FP/SIMD state

From: Ard Biesheuvel <ardb@kernel.org>
Date: 2025-09-19 13:42:27
Also in: linux-efi, lkml

On Fri, 19 Sept 2025 at 13:35, Will Deacon [off-list ref] wrote:
On Thu, Sep 18, 2025 at 12:30:17PM +0200, Ard Biesheuvel wrote:
quoted
From: Ard Biesheuvel <ardb@kernel.org>

Replace the spinlock in the arm64 glue code with a mutex, so that
the CPU can preempted while running the EFI runtime service.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 arch/arm64/kernel/efi.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 0d52414415f3..4372fafde8e9 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -166,15 +166,22 @@ asmlinkage efi_status_t efi_handle_corrupted_x18(efi_status_t s, const char *f)
      return s;
 }

-static DEFINE_RAW_SPINLOCK(efi_rt_lock);
+static DEFINE_MUTEX(efi_rt_lock);

 bool arch_efi_call_virt_setup(void)
 {
      if (!may_use_simd())
              return false;

+     /*
+      * This might be called from a non-sleepable context so try to take the
+      * lock but don't block on it. This should never fail in practice, as
+      * all EFI runtime calls are serialized under the efi_runtime_lock.
+      */
+     if (WARN_ON(!mutex_trylock(&efi_rt_lock)))
+             return false;
If it will never fail in practice, why do we need the lock at all? Can we
just assert that the efi_runtime_lock is held instead and rely on that?
Excellent point.

Do you mean a lockdep assert? efi_runtime_lock is a semaphore, so
there is no is_locked() API that we can BUG() on here.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help