Linux 7.3 Will Guard the System Against Hung EFI Firmware Calls
Translated by a model; the original is in Russian.
Updates to the EFI subsystem have been accepted into the in-development Linux 7.3 kernel. The headline addition is a timeout on the completion of EFI runtime-service calls. Previously the kernel could wait for the firmware to respond indefinitely; now, once the allotted time runs out, the firmware is declared “wedged.” This helps cope with bugs in the EFI/firmware on certain platforms, where a failure can ultimately bring down everything else in user space.
What the problem was
The patch set was the work of Breno Leitão, a Debian developer and kernel engineer at Meta. The trigger was an incident on an NVIDIA Grace–based server. As the author explains in the cover letter, when an EFI runtime-service call hangs inside the firmware, the kworker thread on the efi_rts_wq queue gets stuck inside the call and cannot be cancelled. Meanwhile the kernel waits indefinitely for it to finish, and the caller holds the efi_runtime_lock the entire time.
As a result, every subsequent component that reaches for EFI gets “wedged” — efivarfs, NVRAM writes, set_wakeup_time, ACPI PRM handlers and others — right up until a reboot. The only outward symptom turns out to be a “workqueue lockup” message, while user-space processes hang dead one after another on a semaphore.
In the incident described, the program counters and return addresses pointed into the runtime-services firmware memory: the firmware never returned control, and the thread stayed blocked across hang reports at 127, 157 and 188 seconds — until external monitoring finally rebooted the host.
What the patch does
Leitão stresses that the patch series does not fix the firmware bug itself — that is the vendor's responsibility. The goal is more modest and more practical: to keep a single stuck EFI call from dragging the whole of user space down with it. On top of that, the change turns a baffling “hung thread” into an unambiguous signal in dmesg that the EFI firmware is to blame. That is especially valuable at fleet scale, where the same symptom could otherwise be chalked up to dozens of unrelated causes.
The timeout threshold is set at 120 seconds — comfortably longer than any plausible legitimate call into the EFI runtime services. The addition landed in Linux 7.3 as part of the EFI feature merge.
Source: Phoronix
Comments
Sign in, to comment.