Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755401AbYFTTVX (ORCPT ); Fri, 20 Jun 2008 15:21:23 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752507AbYFTTVP (ORCPT ); Fri, 20 Jun 2008 15:21:15 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:48178 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752037AbYFTTVO (ORCPT ); Fri, 20 Jun 2008 15:21:14 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: "Serge E. Hallyn" Cc: Dave Hansen , Cedric Le Goater , Linux Containers , Andrew Morton , Linux Kernel Mailing List , Pavel Emelianov References: <20071128163728.177495768@fr.ibm.com> <20080620145031.GA30800@us.ibm.com> Date: Fri, 20 Jun 2008 12:11:26 -0700 In-Reply-To: <20080620145031.GA30800@us.ibm.com> (Serge E. Hallyn's message of "Fri, 20 Jun 2008 09:50:31 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SA-Exim-Connect-IP: 24.130.11.59 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-DCC: XMission; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;"Serge E. Hallyn" X-Spam-Relay-Country: X-Spam-Report: * -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa04 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 XM_SPF_Neutral SPF-Neutral Subject: Re: [patch -mm 0/4] mqueue namespace X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on mgr1.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1177 Lines: 29 "Serge E. Hallyn" writes: > > It is unfortunate that two actions are needed to properly complete the > unshare, and we had definately talked about just using the mount before. > I forget why we decided it wasn't practical, so maybe what you describe > solves it... What is worse, and I don't see a way around it: Is that we don't have any callbacks to check where things are mounted. So we can't ensure the proper kind of filesystem is mounted in the right place. That is there is too much freedom in the mount apis to allow for reliable operation. > But at least the current patch reuses CLONE_NEWIPC for posix ipc, which > also seems to make sense. Sort of. I'm really annoyed with whoever did the posix mqueue support. Adding the magic syscall that has to know the internal mount instead of requiring the thing be mounted somewhere and just rejecting filedescriptors for the wrong sorts of files. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/