Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23 |
|
#
d6bdbbdf |
| 31-Mar-2023 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
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 <rafael@kernel.org> Link: https://lore.kernel.org/r/20230331093318.82288-4-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12 |
|
#
48c9899a |
| 14-Feb-2023 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
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/Y+rSXg14z1Myd8Px@dev-arch.thelio-3990X Reported-by: Nathan Chancellor <nathan@kernel.org> Cc: Longlong Xia <xialonglong1@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
d3583f06 |
| 14-Feb-2023 |
Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
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/Y+rSXg14z1Myd8Px@dev-arch.thelio-3990X Reported-by: Nathan Chancellor <nathan@kernel.org> Cc: Longlong Xia <xialonglong1@huawei.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
9d3fe6aa |
| 10-Feb-2023 |
Longlong Xia <xialonglong1@huawei.com> |
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 <xialonglong1@huawei.com> Link: https://lore.kernel.org/r/20230210095444.4067307-4-xialonglong1@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
90a9d5ff |
| 10-Feb-2023 |
Longlong Xia <xialonglong1@huawei.com> |
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 <xialonglong1@huawei.com> Link: https://lore.kernel.org/r/20230210095444.4067307-3-xialonglong1@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.1.11, v6.1.10 |
|
#
5cdc03c5 |
| 01-Feb-2023 |
Longlong Xia <xialonglong1@huawei.com> |
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 <xialonglong1@huawei.com> Link: https://lore.kernel.org/r/20230202033203.1239239-2-xialonglong1@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.1.9, v6.1.8, v6.1.7, v6.1.6 |
|
#
abf08576 |
| 13-Jan-2023 |
Christian Brauner <brauner@kernel.org> |
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 <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
show more ...
|
Revision tags: v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51 |
|
#
31c779f2 |
| 27-Jun-2022 |
Yangxi Xiang <xyangxi5@gmail.com> |
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 <xyangxi5@gmail.com> Link: https://lore.kernel.org/r/20220627120409.11174-1-xyangxi5@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16 |
|
#
8f2d1160 |
| 19-Jan-2022 |
Anthony Iliopoulos <ailiop@suse.com> |
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 <hch@lst.de> Acked-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Anthony Iliopoulos <ailiop@suse.com> Link: https://lore.kernel.org/r/20220119220248.32225-1-ailiop@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
322cbb50 |
| 24-Jan-2022 |
Christoph Hellwig <hch@lst.de> |
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 <hch@lst.de> Reviewed-by: Chaitanya Kulkarni <kch@nvidia.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Link: https://lore.kernel.org/r/20220124093913.742411-4-hch@lst.de Signed-off-by: Jens Axboe <axboe@kernel.dk>
show more ...
|
#
a6097180 |
| 16-Jan-2022 |
NeilBrown <neilb@suse.de> |
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 <christian.brauner@ubuntu.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
Revision tags: v5.15.15, v5.16 |
|
#
28f0c335 |
| 22-Dec-2021 |
Kees Cook <keescook@chromium.org> |
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/20121120215059.GA1859@www.outflux.net/
Cc: ellyjones@chromium.org Cc: Kay Sievers <kay@vrfy.org> Cc: Roland Eggner <edvx1@systemanalysen.net> Co-developed-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Link: https://lore.kernel.org/r/YcMfDOyrg647RCmd@debian-BULLSEYE-live-builder-AMD64 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
d5df2647 |
| 16-Jan-2022 |
NeilBrown <neilb@suse.de> |
devtmpfs regression fix: reconfigure on each mount
commit a6097180d884ddab769fb25588ea8598589c218c upstream.
Prior to Linux v5.4 devtmpfs used mount_single() which treats the given mount options as
devtmpfs regression fix: reconfigure on each mount
commit a6097180d884ddab769fb25588ea8598589c218c upstream.
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 <christian.brauner@ubuntu.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: NeilBrown <neilb@suse.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24 |
|
#
01085e24 |
| 12-Mar-2021 |
Rasmus Villemoes <linux@rasmusvillemoes.dk> |
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 <hch@lst.de> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Link: https://lore.kernel.org/r/20210312103027.2701413-2-linux@rasmusvillemoes.dk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
38f087de |
| 12-Mar-2021 |
Rasmus Villemoes <linux@rasmusvillemoes.dk> |
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 <hch@lst.de> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Link: https://lore.kernel.org/r/20210312103027.2701413-1-linux@rasmusvillemoes.dk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
6521f891 |
| 21-Jan-2021 |
Christian Brauner <christian.brauner@ubuntu.com> |
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/20210121131959.646623-15-christian.brauner@ubuntu.com Cc: Christoph Hellwig <hch@lst.de> Cc: David Howells <dhowells@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
show more ...
|
#
2f221d6f |
| 21-Jan-2021 |
Christian Brauner <christian.brauner@ubuntu.com> |
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/20210121131959.646623-8-christian.brauner@ubuntu.com Cc: Christoph Hellwig <hch@lst.de> Cc: David Howells <dhowells@redhat.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel@vger.kernel.org Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
show more ...
|
#
501ba8bf |
| 12-Mar-2021 |
Rasmus Villemoes <linux@rasmusvillemoes.dk> |
devtmpfs: fix placement of complete() call
[ Upstream commit 38f087de8947700d3b06d3d1594490e0f611c5d1 ]
Calling complete() from within the __init function is wrong - theoretically, the init process
devtmpfs: fix placement of complete() call
[ Upstream commit 38f087de8947700d3b06d3d1594490e0f611c5d1 ]
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 <hch@lst.de> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Link: https://lore.kernel.org/r/20210312103027.2701413-1-linux@rasmusvillemoes.dk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54 |
|
#
4b7ca501 |
| 22-Jul-2020 |
Christoph Hellwig <hch@lst.de> |
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 <hch@lst.de>
show more ...
|
#
db63f1e3 |
| 22-Jul-2020 |
Christoph Hellwig <hch@lst.de> |
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 <hch@lst.de>
show more ...
|
Revision tags: v5.7.10, v5.4.53 |
|
#
c60166f0 |
| 21-Jul-2020 |
Christoph Hellwig <hch@lst.de> |
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 <hch@lst.de>
show more ...
|
#
bcbacc49 |
| 22-Jul-2020 |
Christoph Hellwig <hch@lst.de> |
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 <hch@lst.de>
show more ...
|
Revision tags: v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8 |
|
#
d7167b14 |
| 07-Sep-2019 |
Al Viro <viro@zeniv.linux.org.uk> |
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 <viro@zeniv.linux.org.uk>
|
#
72a9cc95 |
| 15-Jan-2020 |
Rasmus Villemoes <linux@rasmusvillemoes.dk> |
devtmpfs: factor out common tail of devtmpfs_{create,delete}_node
There's some common boilerplate in devtmpfs_{create,delete}_node, put that in a little helper.
Signed-off-by: Rasmus Villemoes <lin
devtmpfs: factor out common tail of devtmpfs_{create,delete}_node
There's some common boilerplate in devtmpfs_{create,delete}_node, put that in a little helper.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Link: https://lore.kernel.org/r/20200115184154.3492-6-linux@rasmusvillemoes.dk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
fad1db8a |
| 15-Jan-2020 |
Rasmus Villemoes <linux@rasmusvillemoes.dk> |
devtmpfs: initify a bit
devtmpfs_mount() is only called from prepare_namespace() in init/do_mounts.c, which is an __init function, so devtmpfs_mount() can also be moved to .init.text.
Then the moun
devtmpfs: initify a bit
devtmpfs_mount() is only called from prepare_namespace() in init/do_mounts.c, which is an __init function, so devtmpfs_mount() can also be moved to .init.text.
Then the mount_dev static variable is only referenced from __init functions (devtmpfs_mount and its initializer function mount_param).
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Link: https://lore.kernel.org/r/20200115184154.3492-5-linux@rasmusvillemoes.dk Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|