This edition looks at three kernel-development discussions moving through the mailing lists and project reports rather than finished features. The community is weighing hazard pointers as an alternative to RCU for reclaiming shared objects, a race-free system call that both creates and opens a directory, and steady progress on the gccrs compiler toward building the kernel. None of these has been merged yet, but each points at where core kernel infrastructure is heading.
Hazard pointers are proposed as an alternative to RCU for object reclamation, a race-free O_CREAT|O_DIRECTORY interface is under discussion, and the gccrs GCC Rust frontend moves closer to compiling the kernel.
The items in this edition are proposals and design discussions, not shipped code. I am covering them because they show the direction of core kernel work, and because understanding a change while it is still being argued is more useful than reading about it after it lands. Each one touches a part of the system that driver and systems engineers work with directly: object lifetime, the system-call interface, and the toolchain.
In this edition
- Hazard pointers as an RCU alternative. The community is considering a hazard-pointer implementation from Mathieu Desnoyers and Paul McKenney that reclaims shared objects with lower memory overhead than RCU in some cases.
- A race-free way to create and open a directory. Work is underway to make O_CREAT|O_DIRECTORY create and open a directory in a single system call, closing a long-standing gap in the interface.
- gccrs moves toward the kernel. The gccrs project spent the first half of 2026 targeting the Linux kernel, giving Rust kernel code a possible second compiler alongside rustc.
Hazard pointers proposed as an alternative to RCU
The kernel’s read-copy-update (RCU) mechanism lets many readers access shared data without locks, and defers freeing an object until it is certain no reader still holds a reference. RCU is used throughout the kernel and works well, but it has a cost: reclamation is deferred until a grace period passes, which can delay the freeing of unused objects and let memory use grow under load. LWN reported on 27 July that the community is considering a hazard-pointer implementation from Mathieu Desnoyers and Paul McKenney as an alternative for some of these cases.
Hazard pointers take a different approach. A reader publishes a pointer to the object it is about to use, and a thread that wants to free an object first checks whether any hazard pointer still refers to it. The trade-off is the reverse of RCU: there is a small, explicit cost on each access to publish the pointer, but reclamation is prompt and the number of objects waiting to be freed is bounded.
That bound is the reason this matters for embedded and real-time systems. RCU’s deferred reclamation is efficient on large servers, but on a memory-constrained device the growth in not-yet-freed objects under load is harder to accept, and the delay before memory returns is less predictable. A mechanism that caps the outstanding memory is worth understanding if you work on drivers or subsystems where footprint and predictability are constraints.
This is a proposal under review, not a merged feature, and RCU is not being replaced. Treat it as background for now: read the design discussion, and keep hazard pointers in mind as a second option the next time you consider RCU and find its memory behaviour awkward for your workload. I would not change any existing code on the strength of a proposal that is still being debated.
A race-free O_CREAT and O_DIRECTORY
Linux has a system call to create a directory, mkdir(), and several variants of open() that can open one, but nothing that does both in a single, race-free step. LWN covered on 30 July that Jori Koolstra has been working to close that gap, most recently by repurposing a combination of open() flags that currently returns an error.
The gap is real. Today you create a directory and then open it as two separate operations, which leaves a window between the two calls:
/* today: two calls, with a race between them */
mkdir(path, 0755);
int fd = open(path, O_DIRECTORY | O_RDONLY);
/* proposed: one call that creates and opens atomically */
int fd = open(path, O_CREAT | O_DIRECTORY | O_RDONLY, 0755);In that window another process can remove or replace the directory, so the descriptor you finally hold may not refer to the object you created. Container runtimes, build systems, and package tools that assemble directory trees under concurrency all have to work around this, usually with extra checks. A single atomic call removes the window.
The discussion also shows why interface changes are slow. O_CREAT|O_DIRECTORY currently returns an error, and some programs may depend on that error. Repurposing the flag combination has to avoid turning an established failure into a surprising success for code that was relying on the old behaviour. This is the recurring difficulty of system-call design: the interface is a permanent contract, and a flag that changes meaning can create a new trap even as it removes an old one. For anyone writing systems software, it is a useful example of why the kernel treats user-space interfaces so cautiously. Wait for the interface to settle before you build on it.
gccrs moves closer to compiling the kernel
The gccrs project is building a Rust frontend for GCC, and LWN reported on 28 July that it spent the first half of 2026 focused on compiling the Linux kernel. By testing the compiler against the kernel’s Rust crates, the developers found and fixed problems in attribute handling, name resolution, and resource management. The compiler can currently handle only simple standalone programs, but the team expects that to advance quickly.
The significance is about reach, not speed. Rust in the kernel is built today with rustc, which uses the LLVM backend, so Rust kernel code is limited to the architectures LLVM supports well. A working GCC frontend would let Rust kernel code be built with GCC, which covers a wider set of architectures, including several that matter in embedded work but are weakly served by LLVM.
A second, independent compiler also reduces the risk of depending on a single toolchain, and it fits the kernel’s long-standing preference for not being locked to one compiler. For teams evaluating whether Rust in the kernel is viable on their target architecture, gccrs is the part worth tracking.
The practical position today is straightforward: gccrs cannot build the kernel yet, so it changes nothing in a current build. What it changes is the outlook. If the progress reported for the first half of 2026 continues, the question of which architectures can run Rust kernel code becomes a toolchain question with a clearer answer. Following the project’s own status reports is the way to judge how fast that is happening. Reasoning about how compiler, kernel, and architecture fit together is exactly the kind of systems thinking we build in our kernel training at TECH VEDA.
References
- Hazard pointers for the kernel — LWN.net (27 Jul 2026)
- Reconsidering O_CREAT|O_DIRECTORY — LWN.net (30 Jul 2026)
- Progress toward compiling Linux with gccrs — LWN.net (28 Jul 2026)
- The gccrs project — status reports
- open(2) manual page and mkdir(2) manual page
- What is RCU? — kernel documentation
— Raghu Bharadwaj
