From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751546AbcFXElb (ORCPT ); Fri, 24 Jun 2016 00:41:31 -0400 Received: from ozlabs.org ([103.22.144.67]:33444 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751038AbcFXEla (ORCPT ); Fri, 24 Jun 2016 00:41:30 -0400 Date: Fri, 24 Jun 2016 14:41:25 +1000 From: Stephen Rothwell To: "Eric W. Biederman" Cc: linux-next@vger.kernel.org, linux-kernel@vger.kernel.org, Jann Horn , Linus Subject: linux-next: manual merge of the userns tree with Linus' tree Message-ID: <20160624144125.78cc4e25@canb.auug.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Eric, Today's linux-next merge of the userns tree got a conflict in: fs/proc/root.c between commit: e54ad7f1ee26 ("proc: prevent stacking filesystems on top") from Linus' tree and commit: e94591d0d90c ("proc: Convert proc_mount to use mount_ns") from the userns tree. I fixed it up (I used the userns version of this file and added the following patch) 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. From: Stephen Rothwell Date: Fri, 24 Jun 2016 14:27:47 +1000 Subject: [PATCH] proc: fixup for "prevent stacking filesystems on top" Signed-off-by: Stephen Rothwell --- fs/proc/inode.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/fs/proc/inode.c b/fs/proc/inode.c index a5b2c33745b7..6b1843e78bd7 100644 --- a/fs/proc/inode.c +++ b/fs/proc/inode.c @@ -463,6 +463,13 @@ int proc_fill_super(struct super_block *s, void *data, int silent) struct inode *root_inode; int ret; + /* + * procfs isn't actually a stacking filesystem; however, there is + * too much magic going on inside it to permit stacking things on + * top of it + */ + s->s_stack_depth = FILESYSTEM_MAX_STACK_DEPTH; + if (!proc_parse_options(data, ns)) return -EINVAL; -- 2.8.1 -- Cheers, Stephen Rothwell