From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752268AbdAZBDq (ORCPT ); Wed, 25 Jan 2017 20:03:46 -0500 Received: from out01.mta.xmission.com ([166.70.13.231]:44574 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751638AbdAZBDp (ORCPT ); Wed, 25 Jan 2017 20:03:45 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Stephen Rothwell Cc: Andrew Morton , linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Aleksa Sarai References: <20170125160835.1b94db55@canb.auug.org.au> Date: Thu, 26 Jan 2017 13:59:23 +1300 In-Reply-To: <20170125160835.1b94db55@canb.auug.org.au> (Stephen Rothwell's message of "Wed, 25 Jan 2017 16:08:35 +1100") Message-ID: <871svqeivo.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=1cWYTR-00034P-Mj;;;mid=<871svqeivo.fsf@xmission.com>;;;hst=in01.mta.xmission.com;;;ip=101.100.131.98;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+ZGf4OqRVY7XTvmKesB+uKlByoJWJfwko= X-SA-Exim-Connect-IP: 101.100.131.98 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.4996] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa07 1397; Body=1 Fuz1=1 Fuz2=1] * 1.0 T_XMDrugObfuBody_08 obfuscated drug references X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;Stephen Rothwell X-Spam-Relay-Country: X-Spam-Timing: total 5303 ms - load_scoreonly_sql: 0.05 (0.0%), signal_user_changed: 5 (0.1%), b_tie_ro: 4.4 (0.1%), parse: 0.73 (0.0%), extract_message_metadata: 11 (0.2%), get_uri_detail_list: 1.20 (0.0%), tests_pri_-1000: 4.6 (0.1%), tests_pri_-950: 1.21 (0.0%), tests_pri_-900: 0.98 (0.0%), tests_pri_-400: 19 (0.4%), check_bayes: 18 (0.3%), b_tokenize: 5 (0.1%), b_tok_get_all: 6 (0.1%), b_comp_prob: 1.81 (0.0%), b_tok_touch_all: 2.5 (0.0%), b_finish: 0.63 (0.0%), tests_pri_0: 176 (3.3%), check_dkim_signature: 0.45 (0.0%), check_dkim_adsp: 2.7 (0.1%), tests_pri_500: 5081 (95.8%), poll_dns_idle: 5075 (95.7%), rewrite_mail: 0.00 (0.0%) Subject: Re: linux-next: manual merge of the akpm-current tree with the userns tree 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 in01.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Stephen Rothwell writes: > Hi all, > > Today's linux-next merge of the akpm-current tree got a conflict in: > > fs/proc/base.c > > between commit: > > 68eb94f16227 ("proc: Better ownership of files for non-dumpable tasks in user namespaces") > > from the userns tree and commit: > > d15d29b5352f ("procfs: change the owner of non-dumpable and writeable files") > > from the akpm-current tree. > > I *think* that the former supercedes the latter? Sort of. After a long conversation it turns out what they are trying to do is orthogonal. The first (mine) is handling the case of non-dumpable tasks in user namespaces. The second by Aleksa Sarai is trying to trying to relax the permission checks in proc so that non-dumpable is not as strict, to sort out some runC issues where they are having challenges coding themselves into a corner. In the case of /proc/self I think there may be a case but in general relaxing the permission checks in proc gives me the Heebie Jeebies. Andrew do you see merit in Aleksa's patch that I don't? Otherwise can you remove it from your tree? > I fixed it up (I just used the former) and can carry the fix as > necessary. This is now fixed as far as linux-next is concerned, but any > non trivial conflicts should be mentioned to your upstream maintainer > when your tree is submitted for merging. You may also want to consider > cooperating with the maintainer of the conflicting tree to minimise any > particularly complex conflicts. Stephen thank you for pointing this out. Eric