OSDN Git Service

bpf/task_iter: In task_file_seq_get_next use task_lookup_next_fd_rcu
authorEric W. Biederman <ebiederm@xmission.com>
Fri, 20 Nov 2020 23:14:33 +0000 (17:14 -0600)
committerEric W. Biederman <ebiederm@xmission.com>
Thu, 10 Dec 2020 18:42:58 +0000 (12:42 -0600)
commit66ed594409a10b1cc6fa1e8d22bc8aed2a080d0c
tree00f17aa05f7a8d6d8a74a7f40265d53b3bd839b9
parent5b17b61870e2f4b0a4fdc5c6039fbdb4ffb796df
bpf/task_iter: In task_file_seq_get_next use task_lookup_next_fd_rcu

When discussing[1] exec and posix file locks it was realized that none
of the callers of get_files_struct fundamentally needed to call
get_files_struct, and that by switching them to helper functions
instead it will both simplify their code and remove unnecessary
increments of files_struct.count.  Those unnecessary increments can
result in exec unnecessarily unsharing files_struct which breaking
posix locks, and it can result in fget_light having to fallback to
fget reducing system performance.

Using task_lookup_next_fd_rcu simplifies task_file_seq_get_next, by
moving the checking for the maximum file descritor into the generic
code, and by remvoing the need for capturing and releasing a reference
on files_struct.  As the reference count of files_struct no longer
needs to be maintained bpf_iter_seq_task_file_info can have it's files
member removed and task_file_seq_get_next no longer needs it's fstruct
argument.

The curr_fd local variable does need to become unsigned to be used
with fnext_task.  As curr_fd is assigned from and assigned a u32
making curr_fd an unsigned int won't cause problems and might prevent
them.

[1] https://lkml.kernel.org/r/20180915160423.GA31461@redhat.com
Suggested-by: Oleg Nesterov <oleg@redhat.com>
v1: https://lkml.kernel.org/r/20200817220425.9389-11-ebiederm@xmission.com
Link: https://lkml.kernel.org/r/20201120231441.29911-16-ebiederm@xmission.com
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
kernel/bpf/task_iter.c