Re: [PATCH 10/17] proc/fd: In proc_readfd_common use fnext_task

On Mon, Aug 17, 2020 at 8:46 PM Eric W. Biederman wrote: > > I am definitely willing to look at it. Do we think there would be enough > traffic on task_lock from /proc//fd access to make it work doing? not from /proc, but bpf iterator in kernel/bpf/task_iter.c that is being modified in the other

Re: [PATCH 10/17] proc/fd: In proc_readfd_common use fnext_task

On Mon, Aug 17, 2020 at 05:04:18PM -0500, Eric W. Biederman wrote: > 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

[PATCH 10/17] proc/fd: In proc_readfd_common use fnext_task

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.