Latest From LWN: Kernel, Programming, and More

posted by Roy Schestowitz on Nov 13, 2025

• GNU/Linux

  • Kernel Space

    • LWN ☛ Namespace reference counting and listns()

      The kernel's namespaces feature is, among other things, a key part of the implementation of containers. Like much in the kernel, though, the namespace API evolved over time; there was no design at the outset. As a result, this API has some rough edges and missing features. Christian Brauner is working to straighten out the namespace situation somewhat with this daunting 72-part patch series that, among other things, adds a new system call to allow user space to query the namespaces present on the system.

      The original namespace type, now called mount namespaces, was introduced by Al Viro as just "namespaces" in 2001 (they were briefly covered in LWN at the time). UTS namespaces (which provide a different view of the system's host name), process-ID namespaces (managing the visibility of processes), and IPC namespaces (controlling the view of the System V inter-process communication features) followed as part of the 2.6.19 release in 2006. Each namespace type was added when the need arose and somebody was moved to implement it. As the use of namespaces has grown, though, some of the problems in their implementation have become more apparent.

    • LWN ☛ The long path toward optimizing short reads

      The kernel's file-I/O subsystems have been highly optimized over the years in the hope of providing the best performance for a wide variety of workloads. There is, however, one workload type that suffers with current kernels: applications that perform many short reads, in multiple processes, from the same file. Kiryl Shutsemau has been working on a patch to try to optimize this case, but the task is turning out to be harder than one might expect.

      As Shutsemau (who has also been known as Kirill Shutemov) explains in the changelog to this relatively short patch, one of the steps in performing a read from a file is locating the relevant folio in the page cache and obtaining a reference to that folio to ensure that it remains stable while the data it contains is copied back to user space. In cases where the reads are short and frequent, though, that reference-count manipulation becomes a significant part of the entire cost; atomic operations are expensive, and bouncing the cache line for the folio around the system makes things even worse. Workloads of this type are measurably slowed by this overhead.

    • LWN ☛ A security model for systemd

      Linux has many security features and tools that have evolved over the years to address threats as they emerge and security gaps as they are discovered. Linux security is all, as Lennart Poettering observed at the All Systems Go! conference held in Berlin, somewhat random and not a ""clean"" design. To many observers, that may also appear to be the case for systemd; however, Poettering said that he does have a vision for how all of the security-related pieces of systemd are meant to fit together. He wanted to use his talk to explain ""how the individual security-related parts of systemd actually fit together and why they exist in the first place"".

      I did not have a chance to attend the All Systems Go! conference this year, but watched the recording of the talk after it was published. The slides are also available.

• Free, Libre, and Open Source Software

  • Programming/Development

    • LWN ☛ Julia 1.12 brings progress on standalone binaries and more

      Julia is a modern programming language that is of particular interest to scientists due to its high performance combined with language features such as Lisp-style macros, an advanced type system, and multiple dispatch. We last looked at Julia in January on the occasion of its 1.11 release. Early in October Julia 1.12 appeared, bringing a handful of quality-of-life improvements for Julia programmers, most notably support, though still experimental and limited, for the creation of binaries.

    • LWN ☛ Mergiraf: syntax-aware merging for Git

      The idea of automatic syntax-aware merging in version-control systems goes back to 2005 or earlier, but initial implementations were often language-specific and slow. Mergiraf is a merge-conflict resolver that uses a generic algorithm plus a small amount of language-specific knowledge to solve conflicts that Git's default strategy cannot. The project's contributors have been working on the tool for just under a year, but it already supports 33 languages, including C, Python, Rust, and even SystemVerilog.

      Mergiraf was started by Antonin Delpeuch, but several other contributors have stepped up to help, of which Ada Alakbarova is the most prolific. The project is written in Rust and licensed under version 3 of the GPL.

      The default Git merge algorithm ("ort") is primarily line-based. It does include some tree-based logic for merging directories, but changes within a single file are merged on a line-by-line basis. That can lead to situations where two logically separate changes that affect the same line cause a merge conflict.

    • Python

      • LWN ☛ An explicit thread-safety proposal for Python

        Python already has several ways to run programs concurrently — including asynchronous functions, threads, subinterpreters, and multiprocessing — but all of those options have drawbacks of one kind or another. PEP 703 ("Making the Global Interpreter Lock Optional in CPython") removed a major barrier to running Python threads in parallel, but also exposed Python programmers to the same tricky synchronization problems found in other languages supporting multithreaded programs. A new draft proposal by Mark Shannon, PEP 805 ("Safe Parallel Python"), suggests a way for the CPython runtime to cut down on concurrency bugs, making it more practical for Python programmers to use versions of the language without the global interpreter lock (GIL).

        The most common concurrency bugs happen when two threads attempt to read and write to the same shared value: a data race. There are many ways to prevent this, such as using a lock, putting constraints into the type system (as Rust does), or even making control over data races a core part of the language. Central to all of these approaches is the observation that data races only occur when there is a mutable value shared between threads without synchronization. Taking away any one of those things (making the value immutable, not sharing it, or synchronizing accesses) makes data races impossible.