From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ram Pai Subject: Re: [rfc patch] how to show propagation state for mounts Date: Wed, 05 Mar 2008 12:23:23 -0800 Message-ID: <1204748604.2911.17.camel@ram.us.ibm.com> References: <20080220160422.GY27894@ZenIV.linux.org.uk> <1203535754.28525.14.camel@ram.us.ibm.com> <20080220211421.GZ27894@ZenIV.linux.org.uk> <20080305192559.GA9702@sergelap.ibm.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: serue@us.ibm.com, viro@ZenIV.linux.org.uk, linux-fsdevel@vger.kernel.org To: Miklos Szeredi Return-path: Received: from e35.co.us.ibm.com ([32.97.110.153]:49943 "EHLO e35.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753534AbYCEUW1 (ORCPT ); Wed, 5 Mar 2008 15:22:27 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m25KMRBW012601 for ; Wed, 5 Mar 2008 15:22:27 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m25KMQjn196768 for ; Wed, 5 Mar 2008 13:22:26 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m25KMQ4G006633 for ; Wed, 5 Mar 2008 13:22:26 -0700 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, 2008-03-05 at 20:34 +0100, Miklos Szeredi wrote: > > > > > If you get down to it, the thing is about delegating control over part > > > > > of namespace to somebody, without letting them control, see, etc. the > > > > > rest of it. So I'd rather be very conservative about extra information > > > > > we allow to piggyback on that. I don't know... perhaps with stable peer > > > > > group IDs it would be OK to show peer group ID by (our) vfsmount + peer > > > > > group ID of master + peer group ID of nearest dominating group that has > > > > > intersection with our namespace. Then we don't leak information (AFAICS), > > > > > get full propagation information between our vfsmounts and cooperating > > > > > tasks in different namespaces can figure the things out as much as possible > > > > > without leaking 3rd-party information to either. > > > > > > > > > > Here's a patch against current -mm implementing this (with some > > > cleanups thrown in). Done some testing on it as well, it wasn't > > > entirey trivial to figure out a setup, where propagation goes out of > > > the namespace first, then comes back in: > > > > Looks nice, and a bit of testing/playing around showed no problem on my > > end. > > Thanks for testing! > > Ram, how is your patch progressing? Could you send me the final > version sometime, so that I can put a new version of this work > together and sumbit to -mm for more eyeballs? Miklos, sorry. will have it your way tonight. Or the latest by the end of the week. RP > > Thanks, > Miklos