Linux 7.4 is set to close files synchronously in three places, close_range, exec and exit, and Phoronix reports much lower latency when many descriptors close at once (Phoronix report). The report does not explain what "synchronous" means here or whether your software is affected. The answers below separate what the public reporting confirms from what you should verify yourself.
What does close_range do, and when do programs use it?
close_range closes every open file descriptor between a first and a last number in a single system call. Without it, a program has to loop and call close once per descriptor, or walk /proc/self/fd to find the open ones. The man page (man 2 close_range) is the authority on the exact arguments, the flags and which kernel and glibc versions provide it.
The man page also describes flags that change the behaviour. One unshares the descriptor table before closing, and another marks descriptors close-on-exec instead of closing them immediately. Check your local man page to confirm what your system supports.
The classic use is code that spawns children. After fork and before exec, the child must not leak the parent's descriptors, so it closes everything above stderr. Process-spawning libraries and container tooling are natural callers. That is an inference from how spawn code works, not something the Phoronix report states.
What changes when closing becomes synchronous?
The Phoronix report says the VFS changes headed for Linux 7.4 close files synchronously for close_range, exec and exit. It says this gives much lower latency than the status quo when many descriptors need closing. This article quotes no benchmark numbers. Look in the pull request for any figures.
The Phoronix report does not spell out the mechanism, so what follows is a plain-language reading, labelled as inference. Closing a descriptor has two parts: removing it from the process's table, and releasing the underlying file once the last reference disappears. "Synchronous" most plausibly means the release work finishes in the calling path instead of being deferred and handled afterwards.
Doing the work inline would avoid per-file deferral overhead, which fits the latency claim. The VFS pull request on the Linux kernel mailing list is the place to confirm the real design, edge cases and caveats. We cover related ground in how to check laptop linux kernel support before 7.4 explained.
| Behaviour | Before 7.4 | With the 7.4 VFS changes | Source and status | |---|---|---|---| | What close_range does | Closes a range of descriptors in one call | No API change reported | man 2 close_range; confirm no change in the pull request | | How files are released on close_range, exec and exit | Described only as the "status quo" | Closed synchronously | Phoronix report | | Latency when closing many descriptors | Higher | "Much lower" per the report | Phoronix report; no figures quoted here, verify in the pull request | | Exact mechanism, affected code paths, corner cases | Not confirmed | Not confirmed | Read the VFS pull request or LKML thread |
Why do exec and exit belong in the same change?
Both tear down descriptors in bulk, just as close_range does. On exec, the kernel closes every descriptor marked close-on-exec before the new program starts. On exit, it closes everything the process still holds. These are the same teardown job reached through different doors, so changing the closing behaviour for all three at once is a coherent design.
Exec and exit also sit on the critical path of anything that starts and stops processes. A parent waiting on a child, or a supervisor restarting a service, sees that teardown time as latency. Whether the saving is visible depends on how many descriptors are open at that moment.
Which workloads are most likely to notice?
Many-descriptor servers. Proxies, databases and connection brokers that hold thousands of sockets and files are the strongest candidates, especially if they exit or re-exec under load. A process holding a handful of descriptors has little to gain.
Process spawners. Build systems, CI runners, shells and language runtimes that fork and exec at high rates close many descriptors per child, particularly with a large descriptor limit. If your spawn path calls close_range, the change applies directly.
Container runtimes and supervisors. Runtimes that scrub inherited descriptors before launching a workload hit the same code. Short-lived containers make start latency more visible. The Phoronix report names no runtime and shows no container measurements, so treat this as a hypothesis to test. For more on this, see full coverage of linux kernel ai-generated code policy: can you submit it?.
Everything else. Desktop apps and ordinary command-line tools probably will not notice anything. Without published measurements, the honest default is "no visible change until your own numbers say otherwise."
How can you check whether your workload is affected?
Start with prerequisites. Run uname -r to confirm your kernel includes the change, and read your distribution's kernel changelog, because the Phoronix report does not say when any distribution will ship it. Then compare the same workload on an older kernel and a 7.4 kernel on identical hardware. Keep the previous kernel in your boot menu so you can reboot back.
Also read: context: fix ea app games on linux: switch proton versions in steam
The commands below are suggestions only. They have not been run, so no output is shown. Run and verify them yourself before relying on any result.
strace -f -T -e trace=close_range,close,execve,exit_group -o trace.txt ./your-program
perf trace -s ./your-program
ls /proc/<pid>/fd | wc -l
The first command records how long each call takes, including in child processes. The second gives a per-syscall summary. The third counts the descriptors a running process holds, which tells you whether the effect could matter at all.
Verify before concluding anything. Confirm that close_range actually appears in the trace, since many programs never call it. Remember that strace adds overhead and can distort short calls, so repeat runs and compare distributions rather than single timings. Kernel-internal teardown during exec and exit will not show up as separate syscalls, so also measure the wall time of the whole spawn or shutdown.
Does synchronous closing mean my program will block longer?
That is the common misreading. "Synchronous" describes when the release work happens, not that total work grows. The report says latency drops when closing many descriptors (Phoronix), so the intended effect is the opposite of slower.
A second misconception is that you need to change code. The Phoronix report mentions no new API or flag, and a kernel-side change should benefit existing callers. The report is thin, though, so confirm any behavioural detail, such as timing guarantees, against the pull request before building on it.
