Until now, a firmware call that never came back could take the rest of your machine with it. The EFI updates merged for the Linux 7.3 kernel, reported on Sunday, August twenty third, 2026, enforce a timeout on EFI runtime service completions instead of waiting forever. Past 120 seconds the kernel declares the firmware wedged, releases the rest of user space from the queue behind it, and writes a log line that names the culprit. The patch series comes from Breno Leitao, a Debian developer and kernel engineer at Meta, who ran into the problem on an NVIDIA Grace server.
The short answer
The EFI updates merged for the Linux 7.3 kernel enforce a timeout on EFI runtime service completions rather than waiting indefinitely. Past 120 seconds the firmware is declared wedged, which stops one stuck call from holding the EFI runtime lock and blocking efivarfs, NVRAM writes and ACPI handlers until the machine is rebooted. The series comes from Breno Leitao, a Debian developer and kernel engineer at Meta, after hitting the problem on an NVIDIA Grace server.
There is a particular kind of incident that eats an afternoon: a machine that is up, answering pings, running its workloads, and yet one specific operation hangs forever and nothing in the logs explains why. If you have ever chased one of those on a UEFI system, the EFI updates in Linux 7.3 are worth reading.
One lock, and everyone behind it
EFI runtime services are the small set of functions the firmware keeps available after boot. They are how the kernel reads and writes EFI variables, changes boot order, and reaches a handful of platform facilities that only firmware knows how to drive.
The important structural detail is that firmware is not reentrant. It cannot handle two callers at once, so the kernel serialises access behind a single EFI runtime lock. Every caller takes that lock, makes its call, and releases it.
That design is fine right up until a call does not return. When firmware wedges mid call, the kernel sits waiting for a completion that will never arrive, and it waits while still holding the lock. Every subsequent caller queues behind a call that has no end. There is no timeout to break the queue and no way to reclaim the lock, so the only exit is a reboot.
The list of things stuck behind that lock is more mundane than it sounds. efivarfs, the interface under /sys/firmware/efi/efivars that tools use to read EFI variables. NVRAM writes, which is what a bootloader installation or a boot order change performs. ACPI handlers that route through runtime services. A monitoring agent that reads a variable on a schedule is enough to find the wall.
What the timeout changes
Breno Leitao, a Debian developer and kernel engineer at Meta, worked through a patch series that puts a deadline on those calls. The threshold is 120 seconds, chosen to sit well beyond any plausible legitimate call into runtime services. Past it, the kernel stops pretending the call is in flight and declares the firmware wedged.
Note carefully what this does not do. It does not repair the firmware, it does not retry the call, and it does not make the platform healthy again. The defect lives in vendor code, which means the real fix is a firmware update or nothing at all.
What the kernel can decide is how far the damage spreads. Before the series, a single vendor bug escalated into a machine wide outage, because the lock it held was the one every other EFI caller needed. After it, the failure stays with the caller that triggered it, and the rest of user space carries on.
That is a familiar pattern in kernel reliability work. You cannot always eliminate a fault, but you can refuse to let it become everybody's fault. The same instinct runs through much of this cycle, from the memory management pull that cut a 705 millisecond KSM stall down to 1.67 milliseconds to the cgroup scheduling rework that puts EEVDF on a single runqueue. Different subsystems, same question: who is allowed to make everyone else wait, and for how long.
The log line is the real feature
The performance framing undersells this change, so it is worth stating the operational half plainly.
Before, a wedged runtime call surfaced as a generic hung task warning. A process blocked for a long time, a stack trace, nothing that points at a cause. That warning looks exactly like a stuck NVMe device, an unresponsive NFS mount or a driver deadlock, so every occurrence starts a fresh investigation from nothing.
After, the kernel says the firmware is at fault. The same incident stops being a mystery and becomes an attribution.
If you run one server, that is a convenience. If you run ten thousand, it is a different category of thing. An unambiguous signal in dmesg is something you can grep for, alert on, count per hardware model and take to a vendor with evidence. A generic stalled task is something an engineer reads. The first scales, the second does not, which is precisely why this came out of an environment operating at that size and surfaced on an NVIDIA Grace server rather than on somebody's desktop.
What to do with it
Nothing, for now, which is the honest answer. There is no tunable to set and no behaviour to opt into. Linux 7.3 is in its merge window, so a stable release is roughly two months away on the usual cadence, and distribution kernels arrive after that. The base everyone is building on today remains Linux 7.2, released in mid August 2026.
The one thing worth doing is retrospective. If you have an unexplained hang in your history where a machine stayed alive but anything touching EFI variables froze, and the resolution in the ticket was a reboot with no root cause, you now have a plausible explanation and a kernel version that would have told you so. Firmware bugs do not announce themselves. Starting with 7.3, at least the kernel will.
Sources and further reading
- Linux 7.3 Better Protects Against Buggy EFI Firmware Taking Down The Rest Of User-Space, Phoronix, August 23, 2026
- Discussion thread mirroring the report, Linux.org
Frequently asked questions
What actually hangs when EFI firmware stops responding?
Everything that needs to talk to firmware afterwards. EFI runtime services are serialised behind a single lock, because the firmware is not reentrant and cannot cope with two callers at once. When a call goes in and never comes back, the kernel keeps waiting while holding that lock, so every later caller queues behind it forever. In practice that means efivarfs, the file system that exposes EFI variables under /sys/firmware/efi/efivars, any NVRAM write such as a boot order change, and the ACPI handlers that route through runtime services. None of them are exotic: a bootloader update, a firmware settings tool or a monitoring agent reading variables is enough to walk straight into the stuck lock.
Why 120 seconds rather than something shorter?
Because the goal is to catch firmware that is broken, not firmware that is slow. Real runtime service calls are expected to finish quickly, but the kernel cannot make hard promises about the slowest legitimate case, since the code doing the work belongs to the vendor and varies by platform. 120 seconds sits far beyond any plausible legitimate call while still being short enough that a machine recovers within a maintenance window rather than staying wedged until someone reboots it. Choosing a tight timeout would risk declaring healthy firmware dead on a platform nobody tested, which is a worse failure than waiting two minutes.
Does this fix the underlying firmware bug?
No, and it does not try to. A firmware bug lives in code the kernel does not own and cannot patch, so fixing it is vendor territory and arrives, if it arrives, as a BIOS or UEFI update. What the kernel can control is the blast radius. Before this series, one vendor defect turned into a system wide outage because the lock was never released. After it, the defect stays contained to the caller that hit it, and the rest of user space keeps running. That distinction matters when you are deciding whether a firmware bug is a fleet emergency or a ticket for the next patch cycle.
How do I tell whether I have hit this?
Look at your logs rather than your symptoms, which is the part of this change that pays off fastest. Previously a wedged runtime call surfaced as a generic hung task warning: some process blocked for a long time, a stack trace, and no clear attribution. That looks identical to a stuck storage device, a wedged network file system mount or a deadlock in a driver, so triage started from zero every time. With the timeout in place the kernel says the firmware is at fault, which turns the same incident into a one line diagnosis. At fleet scale that is the difference between a metric you can alert on and a mystery you investigate by hand.
Do I need to configure anything to get this?
No, it is behaviour rather than a tunable, and it arrives with the kernel. Linux 7.3 is currently in its merge window, so the first release you can run this on is 7.3 itself, which puts a stable build roughly two months out on the usual cadence. Distribution kernels will follow later, and enterprise distributions later still. Nothing about the change alters correct firmware: if your platform returns from runtime service calls the way it should, the timeout never fires and you will never know it is there. That is the ideal shape for a reliability patch, and also the reason it will get very little credit.