emin@budak ~/blog % cat linux-7-3-boundary-work.md
Linux 7.3: The Boundary Work That Matters
Linux 7.3 is a boundary-work release. The headline features are scattered across filesystems, scheduling, virtual machines, and executable loading, but they share a useful direction: make authority, resource policy, and execution context more explicit.
Linus Torvalds released the final kernel on October 18, with the next merge window opening immediately after. The release contains 18,765 non-merge commits from 3,021 developers, according to LWN’s release report. That scale matters less than the shape of the changes. Linux 7.3 spends much of its complexity budget on boundaries that production systems have usually treated as ambient state.
Why Linux 7.3 boundary work matters
Linux 7.3 matters because it turns several weak, implicit contracts into interfaces that software can state and inspect. A process normally inherits a broad view of its filesystem. A cgroup normally shares a scheduler policy selected elsewhere. A virtual machine monitor often infers its working set with expensive page protection tricks. These defaults are convenient until they become the source of a security bug, a latency tail, or an opaque performance regression.
The KernelNewbies 7.3 changelog groups the visible changes: new failfs and fchroot support, cgroup sub-schedulers through sched_ext, working-set tracking for virtual machines, BPF-backed binary format handlers, storage improvements, and FUSE over io_uring work. It is an eclectic list. The engineering pattern is not.
I read the release as a move away from global assumptions. A caller should name the directory handles it needs. A workload group should be able to own its scheduling policy. A VM manager should ask the kernel for the pages it has actually touched. Each change narrows the gap between what an operator intends and what the kernel can enforce.
Failfs makes the filesystem boundary hard
The most interesting Linux 7.3 feature is failfs. The direct answer is that it gives a process a filesystem state where ordinary path lookups fail, rather than merely resolving to an empty directory.
That distinction is easy to underestimate. An empty filesystem still has normal filesystem semantics. A caller can probe it, mount on it, or make decisions based on its presence. Failfs rejects operations that reach it with EOPNOTSUPP. Combined with the new fchroot() system call, a process can put its root and working directory into this failure domain and continue only through directory file descriptors it already holds.
That has a clean security property: code cannot quietly fall back to an absolute path after the boundary is installed. It must carry an explicit capability, in the form of an open descriptor, to reach anything. There is also a race-avoidance benefit. fchroot() accepts a file descriptor rather than resolving a path again, so the call fits the broader Linux trend toward descriptor-based APIs that avoid time-of-check and time-of-use surprises.
This is not a replacement for a container runtime, seccomp, or an LSM policy. It is lower-level. That is why it is useful. Sandboxes that already pass directory descriptors into helpers can reduce the amount of mutable path state they must trust. New designs should treat it as a building block, not a magic confinement switch.
Linux 7.3 gives cgroups a sharper scheduler boundary
The scheduling work is also about making policy local. Linux 7.3 completes cgroup sub-schedulers in sched_ext, allowing different cgroups to use different BPF-based scheduling decisions. The release also changes cgroup scheduling behavior, including a single-runqueue approach and new weight-distribution modes.
That opens a door for teams that run mixed workloads on the same machines. A latency-sensitive service, batch build workers, and a data-processing job do not have to be explained through one global scheduler story. A cgroup can become the unit where an operator expresses its own trade-off.
The danger is obvious. A BPF scheduler turns a kernel policy into software your team now owns. A bad policy can produce worse tails than the default, and it can be difficult to diagnose. The sensible first use is not inventing a clever algorithm. It is making one workload class predictable, measuring it against the default, and keeping a straightforward rollback path.
| Change | Boundary made explicit | Likely engineering use |
|---|---|---|
| failfs plus fchroot | Filesystem reachability | Descriptor-based helpers and sandboxes |
| sched_ext sub-schedulers | Scheduling policy per cgroup | Mixed latency and batch fleets |
| userfaultfd read-write tracking | Guest memory activity | VM working-set and tiering decisions |
| BPF-backed binfmt_misc | Executable dispatch | Specialized runtimes and relocatable systems |
Virtual machines and executable loading get more context
Linux 7.3 adds read-write protection tracking to userfaultfd for VM guest memory. The stated use is working-set tracking for cold-page eviction to tiered or remote storage. The point is not that every VM stack should switch immediately. It is that a VM manager can ask a more specific question than “what pages did I protect and later fault on?”
The executable path gets a similar upgrade. BPF-backed binfmt_misc handlers can programmatically match a binary type and choose an interpreter rather than relying on a fixed string registered in advance. This will matter most to systems with unusual executable layouts, including distribution tooling that needs relocatable behavior. It also deserves a careful threat model. Executable dispatch is an attractive place to gain flexibility and an equally attractive place to hide surprises.
What to test before adopting Linux 7.3
Start with the parts that match an existing pain point. Filesystem-heavy sandboxing code should test failfs with its real descriptor-passing model, including error handling for accidental absolute-path access. Platforms with noisy co-tenancy should prototype one cgroup scheduler policy and compare tail latency, CPU overhead, and recovery behavior. VM operators should validate working-set signals against their current eviction metrics before changing any tiering rule.
Do not treat the release as a reason to flip every new switch. Linux 7.3 offers better primitives for stating boundaries, not a finished policy for every workload. The useful question is narrower: where does your system still rely on an assumption that should become an explicit kernel contract?
For teams that maintain systems near the kernel, that question is worth putting on the next upgrade test plan.
