Skip to content

Commit 157d3d6

Browse files
committed
Merge tag 'vfs-7.0-rc1.namespace' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull vfs mount updates from Christian Brauner: - statmount: accept fd as a parameter Extend struct mnt_id_req with a file descriptor field and a new STATMOUNT_BY_FD flag. When set, statmount() returns mount information for the mount the fd resides on — including detached mounts (unmounted via umount2(MNT_DETACH)). For detached mounts the STATMOUNT_MNT_POINT and STATMOUNT_MNT_NS_ID mask bits are cleared since neither is meaningful. The capability check is skipped for STATMOUNT_BY_FD since holding an fd already implies prior access to the mount and equivalent information is available through fstatfs() and /proc/pid/mountinfo without privilege. Includes comprehensive selftests covering both attached and detached mount cases. - fs: Remove internal old mount API code (1 patch) Now that every in-tree filesystem has been converted to the new mount API, remove all the legacy shim code in fs_context.c that handled unconverted filesystems. This deletes ~280 lines including legacy_init_fs_context(), the legacy_fs_context struct, and associated wrappers. The mount(2) syscall path for userspace remains untouched. Documentation references to the legacy callbacks are cleaned up. - mount: add OPEN_TREE_NAMESPACE to open_tree() Container runtimes currently use CLONE_NEWNS to copy the caller's entire mount namespace — only to then pivot_root() and recursively unmount everything they just copied. With large mount tables and thousands of parallel container launches this creates significant contention on the namespace semaphore. OPEN_TREE_NAMESPACE copies only the specified mount tree (like OPEN_TREE_CLONE) but returns a mount namespace fd instead of a detached mount fd. The new namespace contains the copied tree mounted on top of a clone of the real rootfs. This functions as a combined unshare(CLONE_NEWNS) + pivot_root() in a single syscall. Works with user namespaces: an unshare(CLONE_NEWUSER) followed by OPEN_TREE_NAMESPACE creates a mount namespace owned by the new user namespace. Mount namespace file mounts are excluded from the copy to prevent cycles. Includes ~1000 lines of selftests" * tag 'vfs-7.0-rc1.namespace' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: selftests/open_tree: add OPEN_TREE_NAMESPACE tests mount: add OPEN_TREE_NAMESPACE fs: Remove internal old mount API code selftests: statmount: tests for STATMOUNT_BY_FD statmount: accept fd as a parameter statmount: permission check should return EPERM
2 parents 8113b39 + 1bce1a6 commit 157d3d6

20 files changed

Lines changed: 1669 additions & 365 deletions

File tree

Documentation/filesystems/locking.rst

Lines changed: 0 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -180,7 +180,6 @@ prototypes::
180180
int (*freeze_fs) (struct super_block *);
181181
int (*unfreeze_fs) (struct super_block *);
182182
int (*statfs) (struct dentry *, struct kstatfs *);
183-
int (*remount_fs) (struct super_block *, int *, char *);
184183
void (*umount_begin) (struct super_block *);
185184
int (*show_options)(struct seq_file *, struct dentry *);
186185
ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t);
@@ -204,7 +203,6 @@ sync_fs: read
204203
freeze_fs: write
205204
unfreeze_fs: write
206205
statfs: maybe(read) (see below)
207-
remount_fs: write
208206
umount_begin: no
209207
show_options: no (namespace_sem)
210208
quota_read: no (see below)
@@ -229,22 +227,16 @@ file_system_type
229227

230228
prototypes::
231229

232-
struct dentry *(*mount) (struct file_system_type *, int,
233-
const char *, void *);
234230
void (*kill_sb) (struct super_block *);
235231

236232
locking rules:
237233

238234
======= =========
239235
ops may block
240236
======= =========
241-
mount yes
242237
kill_sb yes
243238
======= =========
244239

245-
->mount() returns ERR_PTR or the root dentry; its superblock should be locked
246-
on return.
247-
248240
->kill_sb() takes a write-locked superblock, does all shutdown work on it,
249241
unlocks and drops the reference.
250242

Documentation/filesystems/mount_api.rst

Lines changed: 0 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -299,8 +299,6 @@ manage the filesystem context. They are as follows:
299299
On success it should return 0. In the case of an error, it should return
300300
a negative error code.
301301

302-
.. Note:: reconfigure is intended as a replacement for remount_fs.
303-
304302

305303
Filesystem context Security
306304
===========================

Documentation/filesystems/porting.rst

Lines changed: 2 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -448,11 +448,8 @@ a file off.
448448

449449
**mandatory**
450450

451-
->get_sb() is gone. Switch to use of ->mount(). Typically it's just
452-
a matter of switching from calling ``get_sb_``... to ``mount_``... and changing
453-
the function type. If you were doing it manually, just switch from setting
454-
->mnt_root to some pointer to returning that pointer. On errors return
455-
ERR_PTR(...).
451+
->get_sb() and ->mount() are gone. Switch to using the new mount API. See
452+
Documentation/filesystems/mount_api.rst for more details.
456453

457454
---
458455

Documentation/filesystems/vfs.rst

Lines changed: 3 additions & 55 deletions
Original file line numberDiff line numberDiff line change
@@ -94,11 +94,9 @@ functions:
9494
9595
The passed struct file_system_type describes your filesystem. When a
9696
request is made to mount a filesystem onto a directory in your
97-
namespace, the VFS will call the appropriate mount() method for the
98-
specific filesystem. New vfsmount referring to the tree returned by
99-
->mount() will be attached to the mountpoint, so that when pathname
100-
resolution reaches the mountpoint it will jump into the root of that
101-
vfsmount.
97+
namespace, the VFS will call the appropriate get_tree() method for the
98+
specific filesystem. See Documentation/filesystems/mount_api.rst
99+
for more details.
102100

103101
You can see all filesystems that are registered to the kernel in the
104102
file /proc/filesystems.
@@ -117,8 +115,6 @@ members are defined:
117115
int fs_flags;
118116
int (*init_fs_context)(struct fs_context *);
119117
const struct fs_parameter_spec *parameters;
120-
struct dentry *(*mount) (struct file_system_type *, int,
121-
const char *, void *);
122118
void (*kill_sb) (struct super_block *);
123119
struct module *owner;
124120
struct file_system_type * next;
@@ -151,10 +147,6 @@ members are defined:
151147
'struct fs_parameter_spec'.
152148
More info in Documentation/filesystems/mount_api.rst.
153149

154-
``mount``
155-
the method to call when a new instance of this filesystem should
156-
be mounted
157-
158150
``kill_sb``
159151
the method to call when an instance of this filesystem should be
160152
shut down
@@ -173,45 +165,6 @@ members are defined:
173165
s_lock_key, s_umount_key, s_vfs_rename_key, s_writers_key,
174166
i_lock_key, i_mutex_key, invalidate_lock_key, i_mutex_dir_key: lockdep-specific
175167

176-
The mount() method has the following arguments:
177-
178-
``struct file_system_type *fs_type``
179-
describes the filesystem, partly initialized by the specific
180-
filesystem code
181-
182-
``int flags``
183-
mount flags
184-
185-
``const char *dev_name``
186-
the device name we are mounting.
187-
188-
``void *data``
189-
arbitrary mount options, usually comes as an ASCII string (see
190-
"Mount Options" section)
191-
192-
The mount() method must return the root dentry of the tree requested by
193-
caller. An active reference to its superblock must be grabbed and the
194-
superblock must be locked. On failure it should return ERR_PTR(error).
195-
196-
The arguments match those of mount(2) and their interpretation depends
197-
on filesystem type. E.g. for block filesystems, dev_name is interpreted
198-
as block device name, that device is opened and if it contains a
199-
suitable filesystem image the method creates and initializes struct
200-
super_block accordingly, returning its root dentry to caller.
201-
202-
->mount() may choose to return a subtree of existing filesystem - it
203-
doesn't have to create a new one. The main result from the caller's
204-
point of view is a reference to dentry at the root of (sub)tree to be
205-
attached; creation of new superblock is a common side effect.
206-
207-
The most interesting member of the superblock structure that the mount()
208-
method fills in is the "s_op" field. This is a pointer to a "struct
209-
super_operations" which describes the next level of the filesystem
210-
implementation.
211-
212-
For more information on mounting (and the new mount API), see
213-
Documentation/filesystems/mount_api.rst.
214-
215168
The Superblock Object
216169
=====================
217170

@@ -244,7 +197,6 @@ filesystem. The following members are defined:
244197
enum freeze_wholder who);
245198
int (*unfreeze_fs) (struct super_block *);
246199
int (*statfs) (struct dentry *, struct kstatfs *);
247-
int (*remount_fs) (struct super_block *, int *, char *);
248200
void (*umount_begin) (struct super_block *);
249201
250202
int (*show_options)(struct seq_file *, struct dentry *);
@@ -351,10 +303,6 @@ or bottom half).
351303
``statfs``
352304
called when the VFS needs to get filesystem statistics.
353305

354-
``remount_fs``
355-
called when the filesystem is remounted. This is called with
356-
the kernel lock held
357-
358306
``umount_begin``
359307
called when the VFS is unmounting a filesystem.
360308

0 commit comments

Comments
 (0)