All of lore.kernel.org
 help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	criu@openvz.org, bpf@vger.kernel.org,
	"Linus Torvalds" <torvalds@linux-foundation.org>,
	"Christian Brauner" <christian.brauner@ubuntu.com>,
	"Oleg Nesterov" <oleg@redhat.com>,
	"Cyrill Gorcunov" <gorcunov@gmail.com>,
	"Jann Horn" <jann@thejh.net>, "Kees Cook" <keescook@chromium.org>,
	"Daniel P. Berrangé" <berrange@redhat.com>,
	"Jeff Layton" <jlayton@redhat.com>,
	"Miklos Szeredi" <miklos@szeredi.hu>,
	"Matthew Wilcox" <willy@debian.org>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	"Matthew Wilcox" <matthew@wil.cx>,
	"Trond Myklebust" <trond.myklebust@fys.uio.no>,
	"Chris Wright" <chrisw@redhat.com>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Martin KaFai Lau" <kafai@fb.com>,
	"Song Liu" <songliubraving@fb.com>, "Yonghong Song" <yhs@fb.com>,
	"Andrii Nakryiko" <andriin@fb.com>,
	"John Fastabend" <john.fastabend@gmail.com>,
	"KP Singh" <kpsingh@chromium.org>
Subject: Re: [PATCH 10/17] proc/fd: In proc_readfd_common use fnext_task
Date: Tue, 18 Aug 2020 03:22:49 +0100	[thread overview]
Message-ID: <20200818022249.GC1236603@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20200817220425.9389-10-ebiederm@xmission.com>

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 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 fnext_task simplifies proc_readfd_common, 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.

Yecchhh...  So you keep locking/unlocking the damn thing for each
descriptor?

  reply	other threads:[~2020-08-18  2:23 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-17 22:03 exec: Move unshare_files and guarantee files_struct.count is correct Eric W. Biederman
2020-08-17 22:04 ` [PATCH 01/17] exec: Move unshare_files to fix posix file locking during exec Eric W. Biederman
2020-08-18 10:04   ` Christian Brauner
2020-08-17 22:04 ` [PATCH 02/17] exec: Simplify unshare_files Eric W. Biederman
2020-08-18 10:08   ` Christian Brauner
2020-08-17 22:04 ` [PATCH 03/17] exec: Remove reset_files_struct Eric W. Biederman
2020-08-18 10:09   ` Christian Brauner
2020-08-17 22:04 ` [PATCH 04/17] kcmp: In kcmp_epoll_target use fget_task Eric W. Biederman
2020-08-20 21:45   ` Cyrill Gorcunov
2020-08-17 22:04 ` [PATCH 05/17] bpf: In bpf_task_fd_query " Eric W. Biederman
2020-08-17 22:04 ` [PATCH 06/17] file: Implement fcheck_task Eric W. Biederman
2020-08-18 10:37   ` Christian Brauner
2020-08-17 22:04 ` [PATCH 07/17] proc/fd: In tid_fd_mode use fcheck_task Eric W. Biederman
2020-08-18 10:36   ` Christian Brauner
2020-08-17 22:04 ` [PATCH 08/17] proc/fd: In proc_fd_link " Eric W. Biederman
2020-08-18 10:36   ` Christian Brauner
2020-08-17 22:04 ` [PATCH 09/17] file: Implement fnext_task Eric W. Biederman
2020-08-17 23:54   ` Linus Torvalds
     [not found]     ` <875z9g7oln.fsf@x220.int.ebiederm.org>
2020-08-18  1:17       ` Linus Torvalds
2020-08-18 11:05         ` Christian Brauner
     [not found]           ` <87pn7m22kn.fsf@x220.int.ebiederm.org>
2020-08-19 15:54             ` Alexei Starovoitov
     [not found]               ` <871rk0t45v.fsf@x220.int.ebiederm.org>
2020-08-21 16:17                 ` Alexei Starovoitov
2020-08-19 18:32             ` Linus Torvalds
2020-08-20 21:50   ` Cyrill Gorcunov
2020-08-17 22:04 ` [PATCH 10/17] proc/fd: In proc_readfd_common use fnext_task Eric W. Biederman
2020-08-18  2:22   ` Al Viro [this message]
     [not found]     ` <87sgck4o23.fsf@x220.int.ebiederm.org>
2020-08-18  4:59       ` Alexei Starovoitov
2020-08-17 22:04 ` [PATCH 11/17] bpf/task_iter: In task_file_seq_get_next " Eric W. Biederman
2020-08-18  5:39   ` kernel test robot
2020-08-18  5:39     ` kernel test robot
2020-08-18 12:54     ` Eric W. Biederman
2020-08-18 12:54       ` Eric W. Biederman
2020-08-17 22:04 ` [PATCH 12/17] proc/fd: In fdinfo seq_show don't use get_files_struct Eric W. Biederman
2020-08-18  0:08   ` Linus Torvalds
     [not found]     ` <87v9hg69ph.fsf@x220.int.ebiederm.org>
2020-08-18  1:21       ` Linus Torvalds
2020-08-18 10:43   ` Christian Brauner
2020-08-17 22:04 ` [PATCH 13/17] file: Remove get_files_struct Eric W. Biederman
2020-08-18 10:39   ` Christian Brauner
2020-08-17 22:04 ` [PATCH 14/17] file: Merge __fd_install into fd_install Eric W. Biederman
2020-08-18 10:15   ` Christian Brauner
2020-08-17 22:04 ` [PATCH 15/17] file: In f_dupfd read RLIMIT_NOFILE once Eric W. Biederman
2020-08-18 10:12   ` Christian Brauner
2020-08-17 22:04 ` [PATCH 16/17] file: Merge __alloc_fd into alloc_fd Eric W. Biederman
2020-08-18 10:17   ` Christian Brauner
2020-08-17 22:04 ` [PATCH 17/17] file: Rename __close_fd to close_fd and remove the files parameter Eric W. Biederman
2020-08-18 10:19   ` Christian Brauner
2020-08-18 11:20   ` Christoph Hellwig
2020-08-18 12:48     ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200818022249.GC1236603@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=berrange@redhat.com \
    --cc=bfields@fieldses.org \
    --cc=bpf@vger.kernel.org \
    --cc=christian.brauner@ubuntu.com \
    --cc=chrisw@redhat.com \
    --cc=criu@openvz.org \
    --cc=daniel@iogearbox.net \
    --cc=ebiederm@xmission.com \
    --cc=gorcunov@gmail.com \
    --cc=jann@thejh.net \
    --cc=jlayton@redhat.com \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=keescook@chromium.org \
    --cc=kpsingh@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=miklos@szeredi.hu \
    --cc=oleg@redhat.com \
    --cc=songliubraving@fb.com \
    --cc=torvalds@linux-foundation.org \
    --cc=trond.myklebust@fys.uio.no \
    --cc=willy@debian.org \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.