Linux Kernel

Linux Kernel: RC3 Stability Push - EFI Memory Fixes and I2C Lock Reverts

Linux 7.0-rc3 drops with critical stability fixes, featuring Linus pulling in an important EFI memory management fix from Ard Biesheuvel and a strategic revert in the i2c i801 driver. The focus is clearly on getting the fundamentals rock solid as we march toward the 7.0 release.

Duration: PT3M47S

https://podlog.io/listen/linux-kernel-654e5f31/episode/linux-kernel-rc3-stability-push-efi-memory-fixes-and-i2c-lock-reverts-348333a2

Transcript

Hey there, kernel hackers! Welcome back to another episode of Linux Kernel. I'm your host, and wow, March 9th 2026 is shaping up to be one of those classic "let's get this right" kind of days in kernel land. You know those days when the focus shifts from shiny new features to making sure everything just works perfectly? That's exactly what we're seeing today.

So Linus has been busy with three commits, and they tell a really interesting story about where we are in the 7.0 development cycle. We're at rc3 now, which means we're in that sweet spot where it's all about polish, stability, and fixing those sneaky edge cases that could bite us later.

Let me start with the big story today - we've got a really important EFI fix coming in from Ard Biesheuvel. Now, EFI might sound like one of those deep, scary kernel subsystems, but this fix is actually a great example of the kind of subtle timing issues that make kernel development so fascinating.

Here's what was happening: on x86 systems, there's this workaround where the kernel keeps EFI boot services memory regions reserved until after something called SetVirtualAddressMap completes. Sounds reasonable, right? But here's the catch - deferred struct page initialization could kick in and basically steal some of that memory permanently. It's like reserving a parking spot but someone else comes along and puts a permanent barrier there while you're still using it.

The fix touches several files in the x86 EFI code, with the bulk of the changes in the quirks file - we're talking about 52 additions and only 3 deletions, so this isn't just a quick bandage. Ard and the team really thought this through to make sure that memory management timing plays nicely together.

Now, the second story is equally interesting but for completely different reasons. We've got a revert in the i2c i801 driver, and you know what? Sometimes a good revert is exactly what we need. The original change tried to replace the ACPI lock with an I2C bus lock, which probably seemed like a great idea at the time. But Wolfram Sang and the i2c maintainers decided the old locking behavior was actually the right approach.

This is such a perfect example of why I love following kernel development. It's not just about moving forward with new code - it's about making the right decisions, even when that means stepping back. The i801 driver handles a ton of hardware out there, so getting the locking right is absolutely critical.

And of course, we have the rc3 tag itself. Just a simple one-line change in the Makefile, but it represents all this work coming together. Version 7.0 is going to be a major milestone, and seeing Linus methodically work through the release candidates gives me so much confidence in what we're building.

What I really love about today's commits is how they show the kernel development process at its best. We've got careful memory management fixes, thoughtful decisions about locking strategies, and steady progress toward a stable release. No drama, no rushed features - just solid, reliable engineering.

For today's focus, if you're working on kernel code or even just following along, pay attention to how these maintainers handle edge cases and timing issues. The EFI fix is a masterclass in thinking through the complete lifecycle of memory management. And that i2c revert? That's a reminder that sometimes the best code change is admitting when something isn't quite right and fixing it properly.

Keep coding, keep learning, and remember - every commit is a step toward making computing better for everyone. We'll be back tomorrow with more kernel adventures. Until then, happy hacking!