[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87a7ohs5ow.fsf@xmission.com>
Date: Sun, 16 Sep 2018 19:38:55 +0200
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Jeff Layton <jlayton@...nel.org>
Cc: viro@...iv.linux.org.uk, berrange@...hat.com,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
Oleg Nesterov <oleg@...hat.com>
Subject: [RFC][PATCH 0/3] exec: Moving unshare_files_struct
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
Powered by blists - more mailing lists