From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1B9AFC10F29 for ; Mon, 9 Mar 2020 20:09:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 049CE24679 for ; Mon, 9 Mar 2020 20:09:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726333AbgCIUJI (ORCPT ); Mon, 9 Mar 2020 16:09:08 -0400 Received: from out03.mta.xmission.com ([166.70.13.233]:37580 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726096AbgCIUJI (ORCPT ); Mon, 9 Mar 2020 16:09:08 -0400 Received: from in01.mta.xmission.com ([166.70.13.51]) by out03.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jBOi1-0004Kc-Kg; Mon, 09 Mar 2020 14:09:05 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1jBOi0-0003E4-PF; Mon, 09 Mar 2020 14:09:05 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Christian Brauner Cc: Bernd Edlinger , Kees Cook , Jann Horn , Jonathan Corbet , Alexander Viro , Andrew Morton , Alexey Dobriyan , Thomas Gleixner , Oleg Nesterov , Frederic Weisbecker , Andrei Vagin , Ingo Molnar , "Peter Zijlstra \(Intel\)" , Yuyang Du , David Hildenbrand , Sebastian Andrzej Siewior , Anshuman Khandual , David Howells , James Morris , Greg Kroah-Hartman , Shakeel Butt , Jason Gunthorpe , Christian Kellner , Andrea Arcangeli , Aleksa Sarai , "Dmitry V. Levin" , "linux-doc\@vger.kernel.org" , "linux-kernel\@vger.kernel.org" , "linux-fsdevel\@vger.kernel.org" , "linux-mm\@kvack.org" , "stable\@vger.kernel.org" , "linux-api\@vger.kernel.org" References: <87v9nlii0b.fsf@x220.int.ebiederm.org> <87a74xi4kz.fsf@x220.int.ebiederm.org> <87r1y8dqqz.fsf@x220.int.ebiederm.org> <87tv32cxmf.fsf_-_@x220.int.ebiederm.org> <87v9ne5y4y.fsf_-_@x220.int.ebiederm.org> <87eeu25y14.fsf_-_@x220.int.ebiederm.org> <20200309195909.h2lv5uawce5wgryx@wittgenstein> Date: Mon, 09 Mar 2020 15:06:46 -0500 In-Reply-To: <20200309195909.h2lv5uawce5wgryx@wittgenstein> (Christian Brauner's message of "Mon, 9 Mar 2020 20:59:09 +0100") Message-ID: <877dztz415.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1jBOi0-0003E4-PF;;;mid=<877dztz415.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+JmhoWzou28F0cqQMkczpEMh7LfXR8OL4= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH v2 3/5] exec: Move cleanup of posix timers on exec out of de_thread X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org Christian Brauner writes: > On Sun, Mar 08, 2020 at 04:36:55PM -0500, Eric W. Biederman wrote: >> >> These functions have very little to do with de_thread move them out >> of de_thread an into flush_old_exec proper so it can be more clearly >> seen what flush_old_exec is doing. >> >> Signed-off-by: "Eric W. Biederman" >> --- >> fs/exec.c | 10 +++++----- >> 1 file changed, 5 insertions(+), 5 deletions(-) >> >> diff --git a/fs/exec.c b/fs/exec.c >> index ff74b9a74d34..215d86f77b63 100644 >> --- a/fs/exec.c >> +++ b/fs/exec.c >> @@ -1189,11 +1189,6 @@ static int de_thread(struct task_struct *tsk) > > While you're cleaning up de_thread() wouldn't it be good to also take > the opportunity and remove the task argument from de_thread(). It's only > ever used with current. Could be done in one of your patches or as a > separate patch. How does that affect the code generation? My sense is that computing current once in flush_old_exec is much better than computing it in each function flush_old_exec calls. I remember that computing current used to be not expensive but noticable. For clarity I can see renaming tsk to me. So that it is clear we are talking about the current process, and not some arbitrary process. And for clarity my goal here is not to clean up de_thread. Though I don't mind that result. My goal is to get the extra work out of de_thread so we can do process tear down cleanups that are safe according to the ordinary process rules, before taking a mutex that protects exec mucking with all of the state in exec. Eric > diff --git a/fs/exec.c b/fs/exec.c > index db17be51b112..ee108707e4b0 100644 > --- a/fs/exec.c > +++ b/fs/exec.c > @@ -1061,8 +1061,9 @@ static int exec_mmap(struct mm_struct *mm) > * disturbing other processes. (Other processes might share the signal > * table via the CLONE_SIGHAND option to clone().) > */ > -static int de_thread(struct task_struct *tsk) > +static int de_thread(void) > { > + struct task_struct *tsk = current; > struct signal_struct *sig = tsk->signal; > struct sighand_struct *oldsighand = tsk->sighand; > spinlock_t *lock = &oldsighand->siglock; > @@ -1266,7 +1267,7 @@ int flush_old_exec(struct linux_binprm * bprm) > * Make sure we have a private signal table and that > * we are unassociated from the previous thread group. > */ > - retval = de_thread(current); > + retval = de_thread(); > if (retval) > goto out;