// HACKER NEWS — CYBERSECURITY
Linux 7.2
Linux 7.2 was tagged and released this week, on the regular schedule.
This cycle was one of the busiest ever, only been beaten by 6.7. This is considered the “new normal”, given that the last 3 or 4 cycles had been pretty busy, especially regarding fixes. There’s some interesting achievements this cycle, like cache-aware scheduling, improvements on MGLRU, the concept of sub-schedulers for sched_ext (a good introduction on the topic by LWN), automatic creation of multi-size transparent hugepages (also a good intro on LWN ) and more - check the LWN articles (part 1 and part 2) for the full picture.
Igalia as usual had a good share of contributions, mainly the DRM scheduler fair policy, which had a regression reported at the 11th hour (see below), hence is present as opt-in. Other than that, we landed very nifty runtime power management for GPUs in the Raspberry Pi 4 and 5, improvements in sched_ext, futex, and general bugfixing. Let’s review the highlights!
For this release cycle we planned to land and enable the DRM scheduler fair policy which brings significant improvements in scenarios where multiple clients are sharing the GPU, and also when a light interactive client competes for the GPU with a demanding one. Unfortunately, due a last-minute regression report during the 7.2-rc7 week, the default policy will remain the old first-in/first-out (FIFO) scheduler. As the fix for the fair policy regression is already known and early testing looks promising, we are hopeful it will get re-enabled in a next kernel release.
We improved sched-ext observability to simplify debugging. When a custom sched-ext scheduler hits a runtime error – such as failing to schedule a task for over 30 seconds – the kernel ejects it and reverts to the default scheduler. To help diagnose these failures, the kernel dumps the status of each CPU. However, especially on high-core systems, these dumps can be truncated due to buffer size limits between kernel space and user space. We mitigated this by prioritizing the exit CPU (the CPU that triggered the error) so it is dumped first, while also surfacing its CPU ID directly to BPF schedulers and userspace tools.
In this release, we landed support for Runtime Power Management on the Raspberry Pi 4 and 5 GPUs.
Until now, the V3D driver had a very simple power model: the GPU clock was enabled during probe and remained enabled for the entire lifetime of the driver. Although this approach was simple and functional, it meant that an idle GPU would still consume power even when it was not actively executing jobs.
With Runtime PM, the GPU is powered only when it is actually processing work, and its clock can be disabled while the GPU is idle. This reduces power consumption when the Raspberry Pi is not using the GPU. We wrote a blog post about this feature with more details and some power measurements.
We also fixed two long-standing bugs in the Raspberry Pi 3 GPU driver that had been affecting RetroPie users for years, causing random GPU hangs and complete system crashes. The problems were traced to how the kernel handled tile memory when the GPU ran out of space while processing a frame. Our fixes ensure that each graphics job only writes to its own memory area and that reused memory is properly cleared before being used again, preventing stale or corrupted data from reaching the GPU. With these fixes, RetroPie users should no longer experience the crashes that could occur while navigating the menus.
Finally, we landed several fixes for GPU resets on Raspberry Pi 4 and 5, making the reset process more reliable and consistent.