From: Christian Brauner <brauner@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christian Brauner <brauner@kernel.org>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [GIT PULL 07/19 for v7.4] vfs close_range
Date: Fri, 16 Oct 2026 12:17:24 +0200 [thread overview]
Message-ID: <20261016-vfs-7.4-rc1.close_range-bfb6cb8d0f6a@brauner> (raw)
In-Reply-To: <20261016-vfs-v74-41eaf6c4712c@brauner>
Hey Linus,
/* Summary */
This adds two new close_range() flags.
CLOSE_RANGE_EXCEPT makes close_range() operate on all file descriptors
outside of [fd, max_fd] instead of the ones inside. Alone it closes
everything but the range. With CLOSE_RANGE_CLOEXEC it marks everything
but the range close-on-exec. With CLOSE_RANGE_UNSHARE dup_fd() never
takes a reference on what is dropped. So a task between
clone(CLONE_FILES | CLONE_VM | CLONE_VFORK) and execve() that has the
descriptors for the child in one window can shed the rest of the shared
table in one call and nothing outside of the window is referenced by
the child at any point.
CLOSE_RANGE_CLOEXEC_ONLY closes the close-on-exec descriptors in the
range and leaves everything else alone. Whatever the caller
deliberately passes down, stdio, LISTEN_FDS, an inherited pipe, stays
where it is. Combined with CLOSE_RANGE_EXCEPT it names the handful of
close-on-exec descriptors that have to survive, the executable or an
error pipe, and closes every other close-on-exec descriptor.
Along the way dup_fd() stops copying a range in the middle of the table
only to close it again. close_range(CLOSE_RANGE_UNSHARE) only avoided
the copy when the range sat at the end of the table. Descriptors in a
skipped range are never copied and no reference is taken on them, so
->flush() isn't called anymore for files from a table they were never
part of. The flags are turned into an enum and selftests cover the
window positions, the shared and the private table and the unshare
form.
/* Testing */
No build failures or warnings were observed.
/* Conflicts */
Merge conflicts with mainline
=============================
No known conflicts.
Merge conflicts with other trees
================================
No known conflicts.
The following changes since commit fd73f4a6659897191fa0d40695fe370925dd3780:
Linux 7.3-rc3 (2026-09-13 14:38:02 -0700)
are available in the Git repository at:
git@gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs tags/vfs-7.4-rc1.close_range
for you to fetch changes up to c73c0e243836d5dfd1c617f73b6003b1ad40b2d1:
Merge patch series "files,close_range: add CLOSE_RANGE_{CLOEXEC_ONLY,EXCEPT}" (2026-10-05 13:02:41 +0200)
----------------------------------------------------------------
vfs-7.4-rc1.close_range
Please consider pulling these changes from the signed vfs-7.4-rc1.close_range tag.
Thanks!
Christian
----------------------------------------------------------------
Christian Brauner (11):
file: let dup_fd() leave the punched hole behind
selftests/core: test the hole CLOSE_RANGE_UNSHARE leaves behind
file: rename dup_fd()'s punch_hole to range
file: let dup_fd() drop everything outside of the range
close_range: turn the flags into an enum
file: add CLOSE_RANGE_EXCEPT
selftests/core: test CLOSE_RANGE_EXCEPT
file: let dup_fd() drop only close-on-exec descriptors
file: add CLOSE_RANGE_CLOEXEC_ONLY
selftests/core: test CLOSE_RANGE_CLOEXEC_ONLY
Merge patch series "files,close_range: add CLOSE_RANGE_{CLOEXEC_ONLY,EXCEPT}"
fs/file.c | 200 ++++-
include/linux/fdtable.h | 9 +
include/uapi/linux/close_range.h | 31 +-
tools/testing/selftests/core/close_range_test.c | 951 ++++++++++++++++++++++++
4 files changed, 1151 insertions(+), 40 deletions(-)
next prev parent reply other threads:[~2026-10-16 10:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 10:13 [GIT PULL 00/19 for v7.4] v7.4 Christian Brauner
2026-10-16 10:14 ` [GIT PULL 01/19 for v7.4] ipc misc Christian Brauner
2026-10-16 10:15 ` [GIT PULL 02/19 for v7.4] kernel signal Christian Brauner
2026-10-16 10:15 ` [GIT PULL 03/19 for v7.4] namespace misc Christian Brauner
2026-10-16 10:16 ` [GIT PULL 04/19 for v7.4] vfs bfs Christian Brauner
2026-10-16 10:16 ` [GIT PULL 05/19 for v7.4] vfs bh Christian Brauner
2026-10-16 10:16 ` [GIT PULL 06/19 for v7.4] vfs binfmt Christian Brauner
2026-10-16 10:17 ` Christian Brauner [this message]
2026-10-16 10:18 ` [GIT PULL 08/19 for v7.4] vfs coredump Christian Brauner
2026-10-16 10:18 ` [GIT PULL 09/19 for v7.4] vfs file Christian Brauner
2026-10-16 10:19 ` [GIT PULL 10/19 for v7.4] vfs idmap Christian Brauner
2026-10-16 10:21 ` [GIT PULL 11/19 for v7.4] vfs iomap Christian Brauner
2026-10-16 10:21 ` [GIT PULL 12/19 for v7.4] vfs kernfs Christian Brauner
2026-10-16 10:22 ` [GIT PULL 13/19 for v7.4] vfs lookup Christian Brauner
2026-10-16 10:23 ` [GIT PULL 14/19 for v7.4] vfs misc Christian Brauner
2026-10-16 10:24 ` [GIT PULL 15/19 for v7.4] vfs mount Christian Brauner
2026-10-16 10:25 ` [GIT PULL 16/19 for v7.4] vfs netfs Christian Brauner
2026-10-16 10:26 ` [GIT PULL 17/19 for v7.4] vfs shared net-next pidfd Christian Brauner
2026-10-16 10:26 ` [GIT PULL 18/19 for v7.4] vfs shared super Christian Brauner
2026-10-16 10:27 ` [GIT PULL 19/19 for v7.4] vfs sync_close Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261016-vfs-7.4-rc1.close_range-bfb6cb8d0f6a@brauner \
--to=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®