125c00af3b
A while ago it was reported that posix file locking goes wrong when a
multi-threaded process calls exec. I looked into the history and this
is definitely a regression, that should be fixed if we can.
This set of changes cleanups of the code in exec so hopefully this code
will not regress again. Then it adds helpers and fixes the users of
files_struct so the reference count is only incremented if COPY_FILES is
passed to clone (or if io_uring takes a reference). Then it removes
helpers (get_files_struct, __install_fd, __alloc_fd, __close_fd) that
are no longer needed and if used would encourage code that increments
the count of files_struct somewhere besides in clone when COPY_FILES is
passed.
In addition to fixing the bug in exec and simplifing the code this set
of changes by virtue of getting files_struct.count correct it optimizes
fdget. With proc and other places not temporarily increasing the count
on files_struct __fget_light should succeed more often in being able to
return a struct file without touching it's reference count.
Fixing the count in files_struct was suggested by Oleg[1].
For those that are interested in the history of this issue I have
included as much of it as I could find in the first change.
Since v1:
- Renamed the functions
__fcheck_files -> files_lookup_fd_raw
fcheck_files -> files_lookup_fd_locked
fcheck_files -> files_lookup_fd_rcu
fcheck_files -> lookup_fd_rcu
fcheck_task -> task_lookup_fd_rcu
fnext_task -> task_lookup_next_fd_rcu
__close_fd_get_file -> close_fd_get_file
- Simplified get_file_raw_ptr
- Removed ksys_close
- Examined the penalty for taking task_lock. The helper
task_lookup_next_fd_rcu takes task_lock each iteration. Concern was
expressed that this might be a problem. The function tid_fd_mode
isn called from tid_fd_revalidate which is called when ever a file
descriptor file is stat'ed, opened, or otherwise accessed. The
function tid_fd_mode histrocally called get_files_struct which took
and dropped task_lock. So the volume of task_lock calls is already
proportional to the number of file descriptors. A micro benchmark
did not see the move to task_lookup_next_fd_rcu making a difference
in performance. Which suggests that the change to taking the task
lock for every file descriptor found in task_lookup_next_fd will not
be a problem.
- Reviewed the code for conflicts with io_uring (especially the
removal of get_files_struct). To my surprise no conflicts were
found as io_uring does not use standard helpers but instead rolls
it's own version of get_files_struct by hand.
Documentation/filesystems/files.rst | 8 +-
arch/powerpc/platforms/cell/spufs/coredump.c | 2 +-
drivers/android/binder.c | 2 +-
fs/autofs/dev-ioctl.c | 5 +-
fs/coredump.c | 5 +-
fs/exec.c | 29 +++----
fs/file.c | 124 +++++++++++++--------------
fs/io_uring.c | 2 +-
fs/locks.c | 14 +--
fs/notify/dnotify/dnotify.c | 2 +-
fs/open.c | 2 +-
fs/proc/fd.c | 48 ++++-------
include/linux/fdtable.h | 40 +++++----
include/linux/syscalls.h | 12 ---
kernel/bpf/syscall.c | 20 +----
kernel/bpf/task_iter.c | 44 +++-------
kernel/fork.c | 12 +--
kernel/kcmp.c | 29 ++-----
18 files changed, 153 insertions(+), 247 deletions(-)
Eric W. Biederman (25):
exec: Don't open code get_close_on_exec
exec: Move unshare_files to fix posix file locking during exec
exec: Simplify unshare_files
exec: Remove reset_files_struct
kcmp: In kcmp_epoll_target use fget_task
bpf: In bpf_task_fd_query use fget_task
proc/fd: In proc_fd_link use fget_task
file: Rename __fcheck_files to files_lookup_fd_raw
file: Factor files_lookup_fd_locked out of fcheck_files
file: Replace fcheck_files with files_lookup_fd_rcu
file: Rename fcheck lookup_fd_rcu
file: Implement task_lookup_fd_rcu
proc/fd: In tid_fd_mode use task_lookup_fd_rcu
kcmp: In get_file_raw_ptr use task_lookup_fd_rcu
file: Implement task_lookup_next_fd_rcu
proc/fd: In proc_readfd_common use task_lookup_next_fd_rcu
bpf/task_iter: In task_file_seq_get_next use task_lookup_next_fd_rcu
proc/fd: In fdinfo seq_show don't use get_files_struct
file: Merge __fd_install into fd_install
file: In f_dupfd read RLIMIT_NOFILE once.
file: Merge __alloc_fd into alloc_fd
file: Rename __close_fd to close_fd and remove the files parameter
file: Replace ksys_close with close_fd
file: Rename __close_fd_get_file close_fd_get_file
file: Remove get_files_struct
[1] https://lkml.kernel.org/r/20180915160423.GA31461@redhat.com
v1: https://lkml.kernel.org/r/87ft8l6ic3.fsf@x220.int.ebiederm.org
Reported-by: Jeff Layton <jlayton@redhat.com>
Reported-by: Daniel P. Berrangé <berrange@redhat.com>
Suggested-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lkml.kernel.org/r/87r1on1v62.fsf@x220.int.ebiederm.org
Link: https://lists.openvz.org/pipermail/criu/2020-November/045123.html
Link: https://marc.info/?l=openvz-criu&m=160591423214257
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
|
||
|---|---|---|
| Documentation | ||
| LICENSES | ||
| arch | ||
| block | ||
| certs | ||
| crypto | ||
| drivers | ||
| fs | ||
| include | ||
| init | ||
| ipc | ||
| kernel | ||
| lib | ||
| mm | ||
| net | ||
| samples | ||
| scripts | ||
| security | ||
| sound | ||
| tools | ||
| usr | ||
| virt | ||
| .clang-format | ||
| .cocciconfig | ||
| .get_maintainer.ignore | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| COPYING | ||
| CREDITS | ||
| Kbuild | ||
| Kconfig | ||
| MAINTAINERS | ||
| Makefile | ||
| README | ||
README
Linux kernel
============
There are several guides for kernel developers and users. These guides can
be rendered in a number of formats, like HTML and PDF. Please read
Documentation/admin-guide/README.rst first.
In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``. The formatted documentation can also be read online at:
https://www.kernel.org/doc/html/latest/
There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.
Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.