On Fri, Sep 19, 2025 at 03:42:12PM +0200, Ard Biesheuvel wrote:

On Fri, 19 Sept 2025 at 13:35, Will Deacon [off-list ref] wrote:

quoted

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.

Yes, I was thinking of lockdep. Even though lockdep doesn't tend to be
enabled in production, just having it in the code is useful documentation
imo.

Will