devtmpfs: don't use vfs_getattr_nosec to query i_mode

The recent move of the bdev_statx call to the low-level vfs_getattr_nosec
helper caused it being used by devtmpfs, which leads to deadlocks in
m

devtmpfs: don't use vfs_getattr_nosec to query i_mode

The recent move of the bdev_statx call to the low-level vfs_getattr_nosec
helper caused it being used by devtmpfs, which leads to deadlocks in
md teardown due to the block device lookup and put interfering with the
unusual lifetime rules in md.

But as handle_remove only works on inodes created and owned by devtmpfs
itself there is no need to use vfs_getattr_nosec vs simply reading the
mode from the inode directly. Switch to that to avoid the bdev lookup
or any other unintentional side effect.

Reported-by: Shin'ichiro Kawasaki <[email protected]>
Reported-by: Xiao Ni <[email protected]>
Fixes: 777d0961ff95 ("fs: move the bdex_statx call to vfs_getattr_nosec")
Signed-off-by: Christoph Hellwig <[email protected]>
Link: https://lore.kernel.org/[email protected]
Tested-by: Shin'ichiro Kawasaki <[email protected]>
Tested-by: Xiao Ni <[email protected]>
Tested-by: Ayush Jain <[email protected]>
Tested-by: Heiko Carstens <[email protected]>
Reviewed-by: Christian Brauner <[email protected]>
Signed-off-by: Christian Brauner <[email protected]>

show more ...

VFS: Change vfs_mkdir() to return the dentry.

vfs_mkdir() does not guarantee to leave the child dentry hashed or make
it positive on success, and in many such cases the filesystem had to use
a diffe

VFS: Change vfs_mkdir() to return the dentry.

vfs_mkdir() does not guarantee to leave the child dentry hashed or make
it positive on success, and in many such cases the filesystem had to use
a different dentry which it can now return.

This patch changes vfs_mkdir() to return the dentry provided by the
filesystems which is hashed and positive when provided. This reduces
the number of cases where the resulting dentry is not positive to a
handful which don't deserve extra efforts.

The only callers of vfs_mkdir() which are interested in the resulting
inode are in-kernel filesystem clients: cachefiles, nfsd, smb/server.
The only filesystems that don't reliably provide the inode are:
- kernfs, tracefs which these clients are unlikely to be interested in
- cifs in some configurations would need to do a lookup to find the
created inode, but doesn't. cifs cannot be exported via NFS, is
unlikely to be used by cachefiles, and smb/server only has a soft
requirement for the inode, so this is unlikely to be a problem in
practice.
- hostfs, nfs, cifs may need to do a lookup (rarely for NFS) and it is
possible for a race to make that lookup fail. Actual failure
is unlikely and providing callers handle negative dentries graceful
they will fail-safe.

So this patch removes the lookup code in nfsd and smb/server and adjusts
them to fail safe if a negative dentry is provided:
- cache-files already fails safe by restarting the task from the
top - it still does with this change, though it no longer calls
cachefiles_put_directory() as that will crash if the dentry is
negative.
- nfsd reports "Server-fault" which it what it used to do if the lookup
failed. This will never happen on any file-systems that it can actually
export, so this is of no consequence. I removed the fh_update()
call as that is not needed and out-of-place. A subsequent
nfsd_create_setattr() call will call fh_update() when needed.
- smb/server only wants the inode to call ksmbd_smb_inherit_owner()
which updates ->i_uid (without calling notify_change() or similar)
which can be safely skipping on cifs (I hope).

If a different dentry is returned, the first one is put. If necessary
the fact that it is new can be determined by comparing pointers. A new
dentry will certainly have a new pointer (as the old is put after the
new is obtained).
Similarly if an error is returned (via ERR_PTR()) the original dentry is
put.

Reviewed-by: Jeff Layton <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Christian Brauner <[email protected]>

show more ...

VFS: change kern_path_locked() and user_path_locked_at() to never return negative dentry

No callers of kern_path_locked() or user_path_locked_at() want a
negative dentry. So change them to return -

VFS: change kern_path_locked() and user_path_locked_at() to never return negative dentry

No callers of kern_path_locked() or user_path_locked_at() want a
negative dentry. So change them to return -ENOENT instead. This
simplifies callers.

This results in a subtle change to bcachefs in that an ioctl will now
return -ENOENT in preference to -EXDEV. I believe this restores the
behaviour to what it was prior to
Commit bbe6a7c899e7 ("bch2_ioctl_subvolume_destroy(): fix locking")

Signed-off-by: NeilBrown <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Paul Moore <[email protected]>
Reviewed-by: Jeff Layton <[email protected]>
Signed-off-by: Christian Brauner <[email protected]>

show more ...

devtmpfs: replace ->mount with ->get_tree in public instance

To finalize mount API conversion, remove the ->mount op from the public
instance in favor of ->get_tree etc. Copy most ops from the under

devtmpfs: replace ->mount with ->get_tree in public instance

To finalize mount API conversion, remove the ->mount op from the public
instance in favor of ->get_tree etc. Copy most ops from the underlying
ops vector (whether it's shmem or ramfs) and substitute our own
->get_tree which simply takes an extra reference on the existing internal
mount as before.

Thanks to Al for the fs_context_for_reconfigure() idea.

Cc: Al Viro <[email protected]>
Cc: Neil Brown <[email protected]>
Signed-off-by: Eric Sandeen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Christian Brauner <[email protected]>

show more ...

driver core: clean up the logic to determine which /sys/dev/ directory to use

When a dev_t is set in a struct device, an symlink in /sys/dev/ is
created for it either under /sys/dev/block/ or /sys/d

driver core: clean up the logic to determine which /sys/dev/ directory to use

When a dev_t is set in a struct device, an symlink in /sys/dev/ is
created for it either under /sys/dev/block/ or /sys/dev/char/ depending
on the device type.

The logic to determine this would trigger off of the class of the
object, and the kobj_type set in that location. But it turns out that
this deep nesting isn't needed at all, as it's either a choice of block
or "everything else" which is a char device. So make the logic a lot
more simple and obvious, and remove the incorrect comments in the code
that tried to document something that was not happening at all (it is
impossible to set class->dev_kobj to NULL as the class core prevented
that from happening.

This removes the only place that class->dev_kobj was being used, so
after this, it can be removed entirely.

Acked-by: Rafael J. Wysocki <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

Revert "devtmpfs: add debug info to handle()"

This reverts commit 90a9d5ff225267b3376f73c19f21174e3b6d7746 as it is
reported to cause boot regressions.

Link: https://lore.kernel.org/r/Y+rSXg14z1Myd

Revert "devtmpfs: add debug info to handle()"

This reverts commit 90a9d5ff225267b3376f73c19f21174e3b6d7746 as it is
reported to cause boot regressions.

Link: https://lore.kernel.org/r/[email protected]
Reported-by: Nathan Chancellor <[email protected]>
Cc: Longlong Xia <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

Revert "devtmpfs: remove return value of devtmpfs_delete_node()"

This reverts commit 9d3fe6aa6b9517408064c7c3134187e8ec77dbf7 as it is
reported to cause boot regressions.

Link: https://lore.kernel.

Revert "devtmpfs: remove return value of devtmpfs_delete_node()"

This reverts commit 9d3fe6aa6b9517408064c7c3134187e8ec77dbf7 as it is
reported to cause boot regressions.

Link: https://lore.kernel.org/r/[email protected]
Reported-by: Nathan Chancellor <[email protected]>
Cc: Longlong Xia <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

devtmpfs: remove return value of devtmpfs_delete_node()

The only caller of device_del() does not check the return value. And
there's nothing we can do when cleaning things up on a remove path.
Let's

devtmpfs: remove return value of devtmpfs_delete_node()

The only caller of device_del() does not check the return value. And
there's nothing we can do when cleaning things up on a remove path.
Let's make it a void function.

Signed-off-by: Longlong Xia <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

devtmpfs: add debug info to handle()

Because handle() is the core function for processing devtmpfs requests,
Let's add some debug info in handle() to help users know why failed.

Signed-off-by: Long

devtmpfs: add debug info to handle()

Because handle() is the core function for processing devtmpfs requests,
Let's add some debug info in handle() to help users know why failed.

Signed-off-by: Longlong Xia <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

devtmpfs: convert to pr_fmt

Use the pr_fmt() macro to prefix all the output with "devtmpfs: ".
while at it, convert printk(<LEVEL>) to pr_<level>().

Signed-off-by: Longlong Xia <xialonglong1@huawei

devtmpfs: convert to pr_fmt

Use the pr_fmt() macro to prefix all the output with "devtmpfs: ".
while at it, convert printk(<LEVEL>) to pr_<level>().

Signed-off-by: Longlong Xia <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

fs: port vfs_*() helpers to struct mnt_idmap

Convert to struct mnt_idmap.

Last cycle we merged the necessary infrastructure in
256c8aed2b42 ("fs: introduce dedicated idmap type for mounts").
This i

fs: port vfs_*() helpers to struct mnt_idmap

Convert to struct mnt_idmap.

Last cycle we merged the necessary infrastructure in
256c8aed2b42 ("fs: introduce dedicated idmap type for mounts").
This is just the conversion to struct mnt_idmap.

Currently we still pass around the plain namespace that was attached to a
mount. This is in general pretty convenient but it makes it easy to
conflate namespaces that are relevant on the filesystem with namespaces
that are relevent on the mount level. Especially for non-vfs developers
without detailed knowledge in this area this can be a potential source for
bugs.

Once the conversion to struct mnt_idmap is done all helpers down to the
really low-level helpers will take a struct mnt_idmap argument instead of
two namespace arguments. This way it becomes impossible to conflate the two
eliminating the possibility of any bugs. All of the vfs and all filesystems
only operate on struct mnt_idmap.

Acked-by: Dave Chinner <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Christian Brauner (Microsoft) <[email protected]>

show more ...

devtmpfs: fix the dangling pointer of global devtmpfsd thread

When the devtmpfs fails to mount, a dangling pointer still remains in
global. Specifically, the err variable is passed by a pointer to t

devtmpfs: fix the dangling pointer of global devtmpfsd thread

When the devtmpfs fails to mount, a dangling pointer still remains in
global. Specifically, the err variable is passed by a pointer to the
devtmpfsd. When the devtmpfsd exits, it sets the error and completes the
setup_done. In this situation, the thread pointer is not set to null.
After the devtmpfsd exited, the devtmpfs can wakes up the destroyed
devtmpfsd thread by wake_up_process if a device change event comes.

Signed-off-by: Yangxi Xiang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

devtmpfs: drop redundant fs parameters from internal fs

The internal_fs_type is mounted via vfs_kernel_mount() and is never
registered as a filesystem, thus specifying the parameters is redundant
as

devtmpfs: drop redundant fs parameters from internal fs

The internal_fs_type is mounted via vfs_kernel_mount() and is never
registered as a filesystem, thus specifying the parameters is redundant
as those params will not be validated by fs_validate_description().

Both {shmem,ramfs}_fs_parameters are anyway validated when those
respective filesystems are first registered, so there is no reason to
pass them to devtmpfs too, drop them.

Reviewed-by: Christoph Hellwig <[email protected]>
Acked-by: Christian Brauner <[email protected]>
Signed-off-by: Anthony Iliopoulos <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

block: remove genhd.h

There is no good reason to keep genhd.h separate from the main blkdev.h
header that includes it. So fold the contents of genhd.h into blkdev.h
and remove genhd.h entirely.

Si

block: remove genhd.h

There is no good reason to keep genhd.h separate from the main blkdev.h
header that includes it. So fold the contents of genhd.h into blkdev.h
and remove genhd.h entirely.

Signed-off-by: Christoph Hellwig <[email protected]>
Reviewed-by: Chaitanya Kulkarni <[email protected]>
Reviewed-by: Martin K. Petersen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jens Axboe <[email protected]>

show more ...

devtmpfs regression fix: reconfigure on each mount

Prior to Linux v5.4 devtmpfs used mount_single() which treats the given
mount options as "remount" options, so it updates the configuration of
the

devtmpfs regression fix: reconfigure on each mount

Prior to Linux v5.4 devtmpfs used mount_single() which treats the given
mount options as "remount" options, so it updates the configuration of
the single super_block on each mount.

Since that was changed, the mount options used for devtmpfs are ignored.
This is a regression which affect systemd - which mounts devtmpfs with
"-o mode=755,size=4m,nr_inodes=1m".

This patch restores the "remount" effect by calling reconfigure_single()

Fixes: d401727ea0d7 ("devtmpfs: don't mix {ramfs,shmem}_fill_super() with mount_single()")
Acked-by: Christian Brauner <[email protected]>
Cc: Al Viro <[email protected]>
Signed-off-by: NeilBrown <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

show more ...

devtmpfs: mount with noexec and nosuid

devtmpfs is writable. Add the noexec and nosuid as default mount flags
to prevent code execution from /dev. The systems who don't use systemd
and who rely on C

devtmpfs: mount with noexec and nosuid

devtmpfs is writable. Add the noexec and nosuid as default mount flags
to prevent code execution from /dev. The systems who don't use systemd
and who rely on CONFIG_DEVTMPFS_MOUNT=y are the ones to be protected by
this patch. Other systems are fine with the udev solution.

No sane program should be relying on executing from /dev. So this patch
reduces the attack surface. It doesn't prevent any specific attack, but
it reduces the possibility that someone can use /dev as a place to put
executable code. Chrome OS has been carrying this patch for several
years. It seems trivial and simple solution to improve the protection of
/dev when CONFIG_DEVTMPFS_MOUNT=y.

Original patch:
https://lore.kernel.org/lkml/[email protected]/

Cc: [email protected]
Cc: Kay Sievers <[email protected]>
Cc: Roland Eggner <[email protected]>
Co-developed-by: Muhammad Usama Anjum <[email protected]>
Signed-off-by: Kees Cook <[email protected]>
Signed-off-by: Muhammad Usama Anjum <[email protected]>
Link: https://lore.kernel.org/r/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

devtmpfs: actually reclaim some init memory

Currently gcc seems to inline devtmpfs_setup() into devtmpfsd(), so
its memory footprint isn't reclaimed as intended. Mark it noinline to
make sure it get

devtmpfs: actually reclaim some init memory

Currently gcc seems to inline devtmpfs_setup() into devtmpfsd(), so
its memory footprint isn't reclaimed as intended. Mark it noinline to
make sure it gets put in .init.text.

While here, setup_done can also be put in .init.data: After complete()
releases the internal spinlock, the completion object is never touched
again by that thread, and the waiting thread doesn't proceed until it
observes ->done while holding that spinlock.

This is now the same pattern as for kthreadd_done in init/main.c:
complete() is done in a __ref function, while the corresponding
wait_for_completion() is in an __init function.

Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

devtmpfs: fix placement of complete() call

Calling complete() from within the __init function is wrong -
theoretically, the init process could proceed all the way to freeing
the init mem before the

devtmpfs: fix placement of complete() call

Calling complete() from within the __init function is wrong -
theoretically, the init process could proceed all the way to freeing
the init mem before the devtmpfsd thread gets to execute the return
instruction in devtmpfs_setup().

In practice, it seems to be harmless as gcc inlines devtmpfs_setup()
into devtmpfsd(). So the calls of the __init functions init_chdir()
etc. actually happen from devtmpfs_setup(), but the __ref on that one
silences modpost (it's all right, because those calls happen before
the complete()). But it does make the __init annotation of the setup
function moot, which we'll fix in a subsequent patch.

Fixes: bcbacc4909f1 ("devtmpfs: refactor devtmpfsd()")
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

namei: prepare for idmapped mounts

The various vfs_*() helpers are called by filesystems or by the vfs
itself to perform core operations such as create, link, mkdir, mknod, rename,
rmdir, tmpfile an

namei: prepare for idmapped mounts

The various vfs_*() helpers are called by filesystems or by the vfs
itself to perform core operations such as create, link, mkdir, mknod, rename,
rmdir, tmpfile and unlink. Enable them to handle idmapped mounts. If the
inode is accessed through an idmapped mount map it into the
mount's user namespace and pass it down. Afterwards the checks and
operations are identical to non-idmapped mounts. If the initial user
namespace is passed nothing changes so non-idmapped mounts will see
identical behavior as before.

Link: https://lore.kernel.org/r/[email protected]
Cc: Christoph Hellwig <[email protected]>
Cc: David Howells <[email protected]>
Cc: Al Viro <[email protected]>
Cc: [email protected]
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Christian Brauner <[email protected]>

show more ...

attr: handle idmapped mounts

When file attributes are changed most filesystems rely on the
setattr_prepare(), setattr_copy(), and notify_change() helpers for
initialization and permission checking.

attr: handle idmapped mounts

When file attributes are changed most filesystems rely on the
setattr_prepare(), setattr_copy(), and notify_change() helpers for
initialization and permission checking. Let them handle idmapped mounts.
If the inode is accessed through an idmapped mount map it into the
mount's user namespace. Afterwards the checks are identical to
non-idmapped mounts. If the initial user namespace is passed nothing
changes so non-idmapped mounts will see identical behavior as before.

Helpers that perform checks on the ia_uid and ia_gid fields in struct
iattr assume that ia_uid and ia_gid are intended values and have already
been mapped correctly at the userspace-kernelspace boundary as we
already do today. If the initial user namespace is passed nothing
changes so non-idmapped mounts will see identical behavior as before.

Link: https://lore.kernel.org/r/[email protected]
Cc: Christoph Hellwig <[email protected]>
Cc: David Howells <[email protected]>
Cc: Al Viro <[email protected]>
Cc: [email protected]
Reviewed-by: Christoph Hellwig <[email protected]>
Signed-off-by: Christian Brauner <[email protected]>

show more ...

init: add an init_chroot helper

Add a simple helper to chroot with a kernel space file name and switch
the early init code over to it. Remove the now unused ksys_chroot.

Signed-off-by: Christoph H

init: add an init_chroot helper

Add a simple helper to chroot with a kernel space file name and switch
the early init code over to it. Remove the now unused ksys_chroot.

Signed-off-by: Christoph Hellwig <[email protected]>

show more ...

init: add an init_chdir helper

Add a simple helper to chdir with a kernel space file name and switch
the early init code over to it. Remove the now unused ksys_chdir.

Signed-off-by: Christoph Hell

init: add an init_chdir helper

Add a simple helper to chdir with a kernel space file name and switch
the early init code over to it. Remove the now unused ksys_chdir.

Signed-off-by: Christoph Hellwig <[email protected]>

show more ...

init: add an init_mount helper

Like do_mount, but takes a kernel pointer for the destination path.
Switch over the mounts in the init code and devtmpfs to it, which
just happen to work due to the im

init: add an init_mount helper

Like do_mount, but takes a kernel pointer for the destination path.
Switch over the mounts in the init code and devtmpfs to it, which
just happen to work due to the implicit set_fs(KERNEL_DS) during early
init right now.

Signed-off-by: Christoph Hellwig <[email protected]>

show more ...

devtmpfs: refactor devtmpfsd()

Split the main worker loop into a separate function. This allows
devtmpfsd_setup to be marked __init, which will allows us to call
__init routines for the setup work.

devtmpfs: refactor devtmpfsd()

Split the main worker loop into a separate function. This allows
devtmpfsd_setup to be marked __init, which will allows us to call
__init routines for the setup work. devtmpfѕ itself needs a __ref
marker for that to work, and a comment explaining why it works.

Signed-off-by: Christoph Hellwig <[email protected]>

show more ...

fs_parse: fold fs_parameter_desc/fs_parameter_spec

The former contains nothing but a pointer to an array of the latter...

Signed-off-by: Al Viro <[email protected]>