From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751322AbdBTWfm (ORCPT ); Mon, 20 Feb 2017 17:35:42 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:39975 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750977AbdBTWfl (ORCPT ); Mon, 20 Feb 2017 17:35:41 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Oleg Nesterov Cc: Andrew Morton , Mika =?utf-8?Q?Penttil?= =?utf-8?Q?=C3=A4?= , Aleksa Sarai , Andy Lutomirski , Attila Fazekas , Jann Horn , Kees Cook , Michal Hocko , Ulrich Obergfell , linux-kernel@vger.kernel.org References: <20170213141452.GA30203@redhat.com> <20170213141516.GA30233@redhat.com> <20170213180454.GA2858@redhat.com> <87zihmpdkf.fsf@xmission.com> <20170220152202.GA13726@redhat.com> Date: Tue, 21 Feb 2017 11:30:56 +1300 In-Reply-To: <20170220152202.GA13726@redhat.com> (Oleg Nesterov's message of "Mon, 20 Feb 2017 16:22:03 +0100") Message-ID: <87vas4wl3z.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1cfwYP-0005tx-4c;;;mid=<87vas4wl3z.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=101.100.131.232;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+T4xLHd87igvuKzVYO/6MOZ8AJfEmJNms= X-SA-Exim-Connect-IP: 101.100.131.232 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.4703] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] * 1.0 T_XMHurry_00 Hurry and Do Something * 0.0 T_TooManySym_01 4+ unique symbols in subject * 0.0 T_TooManySym_02 5+ unique symbols in subject X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Oleg Nesterov X-Spam-Relay-Country: X-Spam-Timing: total 607 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 2.5 (0.4%), b_tie_ro: 1.72 (0.3%), parse: 0.81 (0.1%), extract_message_metadata: 2.1 (0.3%), get_uri_detail_list: 0.60 (0.1%), tests_pri_-1000: 3.9 (0.6%), tests_pri_-950: 1.08 (0.2%), tests_pri_-900: 0.91 (0.1%), tests_pri_-400: 16 (2.6%), check_bayes: 15 (2.5%), b_tokenize: 4.8 (0.8%), b_tok_get_all: 4.9 (0.8%), b_comp_prob: 1.60 (0.3%), b_tok_touch_all: 2.2 (0.4%), b_finish: 0.52 (0.1%), tests_pri_0: 569 (93.6%), check_dkim_signature: 0.46 (0.1%), check_dkim_adsp: 2.8 (0.5%), tests_pri_500: 4.4 (0.7%), rewrite_mail: 0.00 (0.0%) Subject: Re: [PATCH V2 1/2] exec: don't wait for zombie threads with cred_guard_mutex held X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Oleg, My apologies for not replying in-line but I think I can be clearer just saying what I think needs to be said. Today cred_guard_mutex is part of making exec appear to be an atomic operation to ptrace and and proc. To make exec appear to be atomic we do need to take the mutex at the beginning and release it at the end of exec. The semantics of exec appear atomic to ptrace_attach and to proc readers are necessary to ensure we use the proper process credentials in the event of a suid exec. I believe making cred_guard_mutex per task is an option. Reducing the scope of cred_guard_mutex concerns me. There appear to be some fields like sighand that we currently expose in proc that might possibly be problematic. So I am not certain we protect enough things in our proc accessors. Do you know if we can make cred_guard_mutex a per-task lock again? Eric