From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755816AbdDER73 (ORCPT ); Wed, 5 Apr 2017 13:59:29 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:56534 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753323AbdDER7C (ORCPT ); Wed, 5 Apr 2017 13:59:02 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Oleg Nesterov Cc: Andrew Morton , Aleksa Sarai , Andy Lutomirski , Attila Fazekas , Jann Horn , Kees Cook , Michal Hocko , Ulrich Obergfell , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org References: <87tw7axlr0.fsf@xmission.com> <87d1dyw5iw.fsf@xmission.com> <87tw7aunuh.fsf@xmission.com> <87lgsmunmj.fsf_-_@xmission.com> <20170304170312.GB13131@redhat.com> <8760ir192p.fsf@xmission.com> <20170402161518.GC12637@redhat.com> <87inmmbjsq.fsf@xmission.com> <20170403183728.GB31390@redhat.com> <87fuhpjeco.fsf_-_@xmission.com> <20170405160845.GA14536@redhat.com> Date: Wed, 05 Apr 2017 12:53:41 -0500 In-Reply-To: <20170405160845.GA14536@redhat.com> (Oleg Nesterov's message of "Wed, 5 Apr 2017 18:08:45 +0200") Message-ID: <87shlmbv16.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=1cvpCs-0000X2-DP;;;mid=<87shlmbv16.fsf@xmission.com>;;;hst=in02.mta.xmission.com;;;ip=67.3.234.240;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+DJ9aWXFqN+4GcKJj76C5H82+hkm++1LQ= X-SA-Exim-Connect-IP: 67.3.234.240 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 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.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] 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 1550 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 3.7 (0.2%), b_tie_ro: 2.5 (0.2%), parse: 1.45 (0.1%), extract_message_metadata: 6 (0.4%), get_uri_detail_list: 3.4 (0.2%), tests_pri_-1000: 6 (0.4%), tests_pri_-950: 1.74 (0.1%), tests_pri_-900: 1.44 (0.1%), tests_pri_-400: 30 (1.9%), check_bayes: 28 (1.8%), b_tokenize: 12 (0.7%), b_tok_get_all: 8 (0.5%), b_comp_prob: 3.5 (0.2%), b_tok_touch_all: 2.8 (0.2%), b_finish: 0.67 (0.0%), tests_pri_0: 1485 (95.8%), check_dkim_signature: 0.59 (0.0%), check_dkim_adsp: 3.2 (0.2%), tests_pri_500: 3.7 (0.2%), rewrite_mail: 0.00 (0.0%) Subject: Re: scope of cred_guard_mutex. 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 Nesterov writes: > On 04/03, Eric W. Biederman wrote: >> >> You have asked why I have problems with your patch and so I am going to >> try to explain. Partly I want to see a clean set of patches that we >> can merge into Linus's tree before we make any compromises. Because the >> work preparing a clean patchset may inform us of something better. Plus >> we need to make something clean and long term maintainable in any event. >> >> Partly I object because your understanding and my understanding of >> cred_guard_mutex are very different. > > And I think there is another problem, your understanding and my understanding > of "clean" differ too much and it seems that we can not convince each other ;) We have barely begun. You have not shown anyone what your idea of a clean fix actually is. All I have seen from you is a quick hack that is a hack that is back-portable. Focusing on the back port is the wrong order to solve the issue in. We need to solve this in an upstream mergable and maintainable way and then we can worry about backports. >>From a userspace perspective. I find anything in the kernel blocking on a zombie to be just wrong. A zombie is dead. Waiting for a zombie should in all cases be optional. The system should not break if we don't reap a zombie. You have made a clear case that the zombies need to exist for strace -f to wait on. So since the zombies must exist we should make them follow normal zombie rules. With your change exec still blocks waiting for zombies. Furthermore you have to violate the reasonable rule that: * pre-exec resources are guarded with the pre-exec process cred. * post-exec resources are guarded with the post-exec process cred. So from a userspace perspective I think your semantics are absolutely insane. We also need clean code to implement all of this (which I am still inching towards). But we need to be implementing something that makes sense from a userspace perspective. > The last series looks buggy (I'll send more emails later today), but the > main problem is that - in my opinion! - your approach is "obviously wrong > and much less clean". But yes, yes, I understand that this is my opinion, > and I can be wrong. How is changing fixing the implementation so that we don't block waiting for zombies to be reaped wrong? > Eric, I think we need more CC's. Linus, probably security list, the more > the better. > > I am going to resend my series with more CC's, then you can nack it and > explain what you think we should do. Perhaps someone else will suggest > a better solution, or at least review the patches. OK? I will be happy to look but my primary objectionions to your patch were: - You implemented a hack for backporting rather than fixing things cleanly the first time. - You made comments about cred_guard_mutex and it's scope that when I reviewed the code were false. cred_guard_mutex although probably the wrong locking structure is semantically and fundamentally where it needs to be. We can optimize it but we can't change what is protected to make our lives easier. Eric