[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1He6KI-0003Zl-00@dorka.pomaz.szeredi.hu>
Date: Wed, 18 Apr 2007 11:19:46 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: linuxram@...ibm.com
CC: serue@...ibm.com, devel@...nvz.org, linux-kernel@...r.kernel.org,
containers@...ts.osdl.org, viro@....linux.org.uk,
linux-fsdevel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [Devel] Re: [patch 05/10] add "permit user mounts in new
namespace" clone flag
> > Allowing this and other flags to NOT be propagated just makes it
> > possible to have a set of shared mounts with asymmetric properties,
> > which may actually be desirable.
>
> The shared mount feature was designed to ensure that the mount remained
> identical at all the locations.
OK, so remount not propagating mount flags is a bug then?
> Now designing features to make it un-identical but still naming it
> shared, will break its original purpose. Slave mounts were designed
> to make it asymmetric.
What if I want to modify flags in a master mount, but not the slave
mount? Would I be screwed? For example: mount is read-only in both
master and slave. I want to mark it read-write in master but not in
slave. What do I do?
> Whatever feature that is desired to be exploited; can that be exploited
> with the current set of semantics that we have? Is there a real need to
> make the mounts asymmetric but at the same time name them as shared?
> Maybe I dont understand what the desired application is?
I do think this question of propagating mount flags is totally
independent of user mounts.
As it stands, currently remount doesn't propagate mount flags, and I
don't see any compelling reasons why it should.
The patchset introduces a new mount flag "allowusermnt", but I don't
see any compelling reason to propagate this flag _either_.
Please say so if you do have such a reason. As I've explained, having
this flag set differently in parts of a propagation tree does not
interfere with or break propagation in any way.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists