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 15/19 for v7.4] vfs mount
Date: Fri, 16 Oct 2026 12:24:28 +0200 [thread overview]
Message-ID: <20261016-vfs-7.4-rc1.mount-2dea99e7bb3b@brauner> (raw)
In-Reply-To: <20261016-vfs-v74-41eaf6c4712c@brauner>
Hey Linus,
/* Summary */
This adds OPEN_TREE_DROP_MNTNS_MOUNTS.
crun started using OPEN_TREE_NAMESPACE to set up the container's mount
namespace and open_tree(OPEN_TREE_CLONE) for the sources of its bind
mounts. That fails on any host with a mount namespace pinned below such
a source. The recursive clone picks the pinned namespace up and
move_mount() refuses to attach the tree with ELOOP. Only a younger
mount namespace may ever be bound into an older one or mount namespace
references could form a loop. A namespace created with
OPEN_TREE_NAMESPACE is younger than everything else on the system so
from inside it every pinned namespace is older.
By the time this fails setns() has run and the host tree is out of
reach, so the runtime has to predict the situation beforehand and lose
the optimization. snapd pins mount namespaces under /run/snapd/ns so on
Ubuntu that is any container bind mounting the host root.
Every other path crossing a mount namespace boundary already leaves
these mounts behind, copy_mnt_ns() and create_new_namespace() both do.
Only get_detached_copy() asks for them. The new flag lets a caller get
a clone without them. It stays opt-in because open_tree(OPEN_TREE_CLONE)
plus move_mount() is mount --rbind through a file descriptor and
dropping them by default would silently lose /run/snapd/ns/*.mnt on a
live system. It requires AT_RECURSIVE, is a no-op with
OPEN_TREE_NAMESPACE and skips locked nsfs mounts the way copy_mnt_ns()
does, so nothing new is exposed. Selftests are included.
/* 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 24a19b953e2a3d0ea5a8c4951a0ab8f32720c907:
Linux 7.3-rc7 (2026-10-11 20:04:55 -0700)
are available in the Git repository at:
git@gitolite.kernel.org:pub/scm/linux/kernel/git/vfs/vfs tags/vfs-7.4-rc1.mount
for you to fetch changes up to 062b32e4b55082f11b63dce22c78cd00fc6c7ed5:
Merge patch series "mount: add OPEN_TREE_DROP_MNTNS_MOUNTS" (2026-10-12 11:33:23 +0200)
----------------------------------------------------------------
vfs-7.4-rc1.mount
Please consider pulling these changes from the signed vfs-7.4-rc1.mount tag.
Thanks!
Christian
----------------------------------------------------------------
Christian Brauner (1):
Merge patch series "mount: add OPEN_TREE_DROP_MNTNS_MOUNTS"
Kir Kolyshkin (2):
mount: add OPEN_TREE_DROP_MNTNS_MOUNTS
selftests/filesystems: test OPEN_TREE_DROP_MNTNS_MOUNTS
fs/namespace.c | 16 +-
include/uapi/linux/mount.h | 1 +
.../filesystems/open_tree_ns/open_tree_ns_test.c | 193 +++++++++++++++++++++
3 files changed, 208 insertions(+), 2 deletions(-)
next prev parent reply other threads:[~2026-10-16 10:25 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 ` [GIT PULL 07/19 for v7.4] vfs close_range Christian Brauner
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 ` Christian Brauner [this message]
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.mount-2dea99e7bb3b@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®