news
LWN on Blender, Kernel, and Rust
-
Applications
-
LWN ☛ Blender 4.5 brings big changes
Blender 4.5 LTS was released on July 15, 2025, and will be supported through 2027. This is the last feature release of the 3D graphics-creation suite's 4.x series; it includes quality-of-life improvements, including work to bring the Vulkan backend up to par with the default OpenGL backend. With 4.5 released, Blender developers are turning their attention toward Blender 5.0, planned for release later this year. It will introduce substantial changes, particularly in the Geometry Nodes system, a central feature of Blender's procedural workflows.
Brief introduction
Blender is an open-source creative application released under the GPLv3. The Blender Foundation stewards development, with significant funding from the Blender Development Fund as well as backing from individual contributors and industry sponsors. Its code is primarily written in C and C++, with Python used extensively for scripting and add-ons.
-
-
Kernel Space
-
LWN ☛ Extending the time-slice-extension discussion
Time-slice extension is a proposed scheduler feature that would allow a user-space process to request to not be preempted for a short period while it executes a critical section. It is an idea that has been circulating for years, but efforts to implement it became more serious in February of this year. The latest developer to make an attempt at time-slice extension is Thomas Gleixner, who has posted a new patch set with a reworked API. Chances are good that this implementation is close to what will actually be adopted by the kernel.
Imagine a user-space thread that holds a (user-space) spinlock; if that thread is preempted by another thread which subsequently attempts to acquire that same lock, the preempting thread will spin indefinitely, having displaced the thread that could release the lock. That is not a path toward optimal performance. If, though, the lock-holding thread could ask to not be preempted while holding the lock, this scenario could be avoided; time-slice extension is meant to at least give that thread a chance to run long enough to finish its work before being kicked out of the CPU.
-
LWN ☛ Multiple kernels on a single system
The Linux kernel generally wants to be in charge of the system as a whole; it runs on all of the available CPUs and controls access to them globally. Cong Wang has just come forward with a different approach: allowing each CPU to run its own kernel. The patch set is in an early form, but it gives a hint for what might be possible.
The patch set as a whole only touches 1,400 lines of code, adding a few basic features; there would clearly need to be a lot more work done to make this feature useful. The first part is a new KEXEC_MULTIKERNEL flag to the kexec_load() system call, requesting that a new kernel be booted on a specific CPU. That CPU must be in the offline state when the call is made, or the call will fail with an EBUSY error. It would appear that it is only possible to assign a single CPU to any given kernel in this mode; the current interface lacks a way to specify more than one CPU. There is a bunch of x86-64 assembly magic to set up the target CPU for the new kernel and to boot it there.
-
LWN ☛ Revocable references for transient devices
Computers were once relatively static devices; if a peripheral was present at boot, it was unlikely to disappear while the system was operating. Those days are far behind us, though; devices can come and go at any time, often with no notice. That impermanence can create challenges for kernel code, which may not be expecting resources it is managing to make an abrupt exit. The revocable resource management patch set from Tzung-Bi Shih is meant to help with the creation of more robust — and more secure — kernel subsystems in a dynamic world.
Low-level drivers that manage transient devices must be prepared for those devices to vanish; there is no way around that. But those drivers often create data structures that are associated with the devices they manage, and export those structures to higher-level software. That creates a different sort of problem: the low-level driver knows when it can no longer communicate with a departed device, but it can be harder to know when it can safely free those data structures. Higher-level code may hold references to those structures for some time after the device disappears; freeing them prematurely would expose the kernel to use-after-free bugs and the exploits that are likely to follow.
-
-
Rust
-
LWN ☛ Canceling asynchronous Rust
Asynchronous Rust code has what Rain Paharia calls a ""universal cancellation protocol"", meaning that any asynchronous code can be interrupted in the same way. They claim that this is both a useful feature when used deliberately, and a source of errors when done by accident. They presented about this problem at RustConf 2025, offering a handful of techniques to avoid introducing bugs into asynchronous Rust code.
-