Re: [PATCH v3 0/7] efi/runtime-wrappers: bound the wait for EFI runtime service calls
Breno Leitao <[email protected]> Fri, 10 Jul 2026 03:06:43 -0700
| Newsgroups | org.kernel.vger.linux-efi,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Thu, Jul 09, 2026 at 08:02:28AM +0300, Ard Biesheuvel wrote: > > > On Wed, 1 Jul 2026, at 15:28, Breno Leitao wrote: > > Hello Ard, > > > > On Tue, Jun 16, 2026 at 05:09:33AM -0700, Breno Leitao wrote: > >> When an EFI runtime service call hangs in firmware, the kworker on > >> efi_rts_wq is stuck inside the firmware call and cannot be cancelled. > >> The kernel currently waits indefinitely on the completion, and the > >> caller holds efi_runtime_lock for the duration, so every subsequent > >> EFI runtime caller (efivarfs, NVRAM writes, set_wakeup_time, ACPI PRM > >> handlers, ...) is wedged until reboot. The only externally visible > >> symptom is a "workqueue lockup" message and userspace processes > >> piling up uninterruptibly on the semaphore. > > > > I'd appreciate your thoughts on this approach. Is there anything you'd > > like me to adjust or improve before we move forward? > > > > This looks fine now, apologies for the delayed response. > > I've queued this up for v7.3 Thanks, Ard. We got two reports that I would like to address: 1) efi_rts_park_worker() should be tagged as __noreturn https://lore.kernel.org/all/[email protected]/ 2) efi_runtime_lock_owner() is undeclared in some kernel config https://lore.kernel.org/all/[email protected]/ Do you want me to respin this series, or, some fixes on top of current tree? Thanks, --breno