All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Jeff Layton <jlayton@kernel.org>
Cc: viro@zeniv.linux.org.uk, berrange@redhat.com,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Oleg Nesterov <oleg@redhat.com>
Subject: [RFC][PATCH 0/3] exec: Moving unshare_files_struct
Date: Sun, 16 Sep 2018 19:38:55 +0200	[thread overview]
Message-ID: <87a7ohs5ow.fsf@xmission.com> (raw)
In-Reply-To: <20180914105310.6454-1-jlayton@kernel.org> (Jeff Layton's message of "Fri, 14 Sep 2018 06:53:07 -0400")


Paired with Oleg's patch to reduce the number of callers of
get_files_struct it looks like we can simplify the basic idea of moving
unshare_files in exec by quite a bit so that in net we have fewer lines
of code.

The big simplification from Jeff's verion is that we take advantage
of calling unshare_files past the point of no return.  Which removes
the need for cleanup, and restoring ->files.  Which removes the
need for blocking clone and unshare.

Oleg's patch to remove get_files_struct from proc means we don't need
two counts in files_struct.

Which leaves us with the question of what are the races in fs/exec.c
with respect to accessing files.  Semantically I don't think we care
but we do need to be certain the implementation of exec is still robust.

These patches are still rough and ready and only compile tested but I
believe they demonstrate what is possible.

Eric W. Biederman (3):
      exec: Move unshare_files down to avoid locks being dropped on exec.
      exec: Simplify unshare_files
      exec: Remove reset_files_struct

 fs/coredump.c           |  5 +----
 fs/exec.c               | 16 +++++-----------
 fs/file.c               | 12 ------------
 include/linux/fdtable.h |  3 +--
 kernel/fork.c           | 12 ++++++------
 5 files changed, 13 insertions(+), 35 deletions(-)

Eric

  parent reply	other threads:[~2018-09-16 17:38 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-14 10:53 [PATCH v3 0/3] exec: fix passing of file locks across execve in multithreaded processes Jeff Layton
2018-09-14 10:53 ` [PATCH v3 1/3] exec: separate thread_count for files_struct Jeff Layton
2018-09-15 16:04   ` Oleg Nesterov
2018-09-16 16:10     ` Eric W. Biederman
2018-09-17 15:24       ` Oleg Nesterov
2018-09-17 20:45         ` Eric W. Biederman
2018-09-14 10:53 ` [PATCH v3 2/3] exec: delay clone(CLONE_FILES) if task associated with current files_struct is exec'ing Jeff Layton
2018-09-14 10:53 ` [PATCH v3 3/3] exec: do unshare_files after de_thread Jeff Layton
2018-09-15 16:37   ` Oleg Nesterov
2018-09-16 16:49     ` Eric W. Biederman
2018-09-17 15:28       ` Oleg Nesterov
2018-09-16 16:59   ` Eric W. Biederman
2018-09-16 17:38 ` Eric W. Biederman [this message]
2018-09-16 17:39   ` [RFC][PATCH 1/3] exec: Move unshare_files down to avoid locks being dropped on exec Eric W. Biederman
2018-09-17 15:49     ` Oleg Nesterov
2018-09-16 17:40   ` [RFC][PATCH 2/3] exec: Simplify unshare_files Eric W. Biederman
2018-09-17 16:23     ` Oleg Nesterov
2018-09-17 20:26       ` Eric W. Biederman
2018-09-16 17:41   ` [RFC][PATCH 3/3] exec: Remove reset_files_struct Eric W. Biederman
2018-09-17 15:59   ` [RFC][PATCH 0/3] exec: Moving unshare_files_struct Oleg Nesterov
2018-09-18 22:18     ` Eric W. Biederman
2018-09-17 16:24   ` Jeff Layton

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=87a7ohs5ow.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=berrange@redhat.com \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /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.