kernel/git/next/linux-next.git/fs/kernel_read_file.c, branch master

fs: use scoped_with_init_fs() for kernel_read_file_from_path_initns()

2026-06-29T08:44:09+00:00

Replace the manual init_task root retrieval with scoped_with_init_fs() to temporarily override current->fs. This allows using the simpler filp_open() instead of the init_root() + file_open_root() pattern. kernel_read_file_from_path_initns() ← fw_get_filesystem_firmware() ← _request_firmware() ← request_firmware_work_func() ← kworker (async firmware loading) Also called synchronously from request_firmware() which can be user or kthread context. Link: https://patch.msgid.link/20260601-work-kthread-nullfs-v4-12-77ee053060e0@kernel.org Signed-off-by: Christian Brauner (Amutable)

fdget(), trivial conversions

2024-11-03T06:28:06+00:00

fdget() is the first thing done in scope, all matching fdput() are immediately followed by leaving the scope. Reviewed-by: Christian Brauner Signed-off-by: Al Viro

introduce fd_file(), convert all accessors to it.

2024-08-13T02:00:43+00:00

For any changes of struct fd representation we need to turn existing accesses to fields into calls of wrappers. Accesses to struct fd::flags are very few (3 in linux/file.h, 1 in net/socket.c, 3 in fs/overlayfs/file.c and 3 more in explicit initializers). Those can be dealt with in the commit converting to new layout; accesses to struct fd::file are too many for that. This commit converts (almost) all of f.file to fd_file(f). It's not entirely mechanical ('file' is used as a member name more than just in struct fd) and it does not even attempt to distinguish the uses in pointer context from those in boolean context; the latter will be eventually turned into a separate helper (fd_empty()). NOTE: mass conversion to fd_empty(), tempting as it might be, is a bad idea; better do that piecewise in commit that convert from fdget...() to CLASS(...). [conflicts in fs/fhandle.c, kernel/bpf/syscall.c, mm/memcontrol.c caught by git; fs/stat.c one got caught by git grep] [fs/xattr.c conflict] Reviewed-by: Christian Brauner Signed-off-by: Al Viro

fs: Fix kernel-doc warnings

2023-08-19T10:12:12+00:00

These have a variety of causes and a corresponding variety of solutions. Signed-off-by: "Matthew Wilcox (Oracle)" Message-Id: <20230818200824.2720007-1-willy@infradead.org> Signed-off-by: Christian Brauner

fs/kernel_read_file: allow to read files up-to ssize_t

2022-06-17T02:58:21+00:00

Patch series "Allow to kexec with initramfs larger than 2G", v2. Currently, the largest initramfs that is supported by kexec_file_load() syscall is 2G. This is because kernel_read_file() returns int, and is limited to INT_MAX or 2G. On the other hand, there are kexec based boot loaders (i.e. u-root), that may need to boot netboot images that might be larger than 2G. The first patch changes the return type from int to ssize_t in kernel_read_file* functions. The second patch increases the maximum initramfs file size to 4G. Tested: verified that can kexec_file_load() works with 4G initramfs on x86_64. This patch (of 2): Currently, the maximum file size that is supported is 2G. This may be too small in some cases. For example, kexec_file_load() system call loads initramfs. In some netboot cases initramfs can be rather large. Allow to use up-to ssize_t bytes. The callers still can limit the maximum file size via buf_size. Link: https://lkml.kernel.org/r/20220527025535.3953665-1-pasha.tatashin@soleen.com Link: https://lkml.kernel.org/r/20220527025535.3953665-2-pasha.tatashin@soleen.com Signed-off-by: Pasha Tatashin Cc: Al Viro Cc: Baoquan He Cc: "Eric W. Biederman" Cc: Greg Thelen Cc: Sasha Levin Signed-off-by: Andrew Morton

vfs: check fd has read access in kernel_read_file_from_fd()

2021-10-19T06:22:03+00:00

If we open a file without read access and then pass the fd to a syscall whose implementation calls kernel_read_file_from_fd(), we get a warning from __kernel_read(): if (WARN_ON_ONCE(!(file->f_mode & FMODE_READ))) This currently affects both finit_module() and kexec_file_load(), but it could affect other syscalls in the future. Link: https://lkml.kernel.org/r/20211007220110.600005-1-willy@infradead.org Fixes: b844f0ecbc56 ("vfs: define kernel_copy_file_from_fd()") Signed-off-by: Matthew Wilcox (Oracle) Reported-by: Hao Sun Reviewed-by: Kees Cook Acked-by: Christian Brauner Cc: Al Viro Cc: Mimi Zohar Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

switch file_open_root() to struct path

2021-04-07T17:56:43+00:00

... and provide file_open_root_mnt(), using the root of given mount. Signed-off-by: Al Viro

fs/kernel_file_read: Add "offset" arg for partial reads

2020-10-05T11:37:04+00:00

To perform partial reads, callers of kernel_read_file*() must have a non-NULL file_size argument and a preallocated buffer. The new "offset" argument can then be used to seek to specific locations in the file to fill the buffer to, at most, "buf_size" per call. Where possible, the LSM hooks can report whether a full file has been read or not so that the contents can be reasoned about. Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20201002173828.2099543-14-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman

LSM: Add "contents" flag to kernel_read_file hook

2020-10-05T11:37:03+00:00

As with the kernel_load_data LSM hook, add a "contents" flag to the kernel_read_file LSM hook that indicates whether the LSM can expect a matching call to the kernel_post_read_file LSM hook with the full contents of the file. With the coming addition of partial file read support for kernel_read_file*() API, the LSM will no longer be able to always see the entire contents of a file during the read calls. For cases where the LSM must read examine the complete file contents, it will need to do so on its own every time the kernel_read_file hook is called with contents=false (or reject such cases). Adjust all existing LSMs to retain existing behavior. Signed-off-by: Kees Cook Reviewed-by: Mimi Zohar Link: https://lore.kernel.org/r/20201002173828.2099543-12-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman

fs/kernel_read_file: Add file_size output argument

2020-10-05T11:37:03+00:00

In preparation for adding partial read support, add an optional output argument to kernel_read_file*() that reports the file size so callers can reason more easily about their reading progress. Signed-off-by: Kees Cook Reviewed-by: Mimi Zohar Reviewed-by: Luis Chamberlain Reviewed-by: James Morris Acked-by: Scott Branden Link: https://lore.kernel.org/r/20201002173828.2099543-8-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman