On Mon, 2007-04-09 at 12:07 -0500, Serge E. Hallyn wrote:
> Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> > - need to set up mount propagation from global namespace to private
> >ones, mount(8) does not yet have options to configure propagation
>
> Hmm, I guess I get lost using my own little
On Mon, 2007-04-09 at 22:10 +0200, Miklos Szeredi wrote:
> > > The one in pam-0.99.6.3-29.1 in opensuse-10.2 is totally broken. Are
> > > you interested in the details? I can reproduce it, but forgot to note
> > > down the details of the brokenness.
> >
> > I don't know how far removed that is f
On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
> > 1. clone the master namespace.
> >
> > 2. in the new namespace
> >
> > move the tree under /share/$me to /
> > for each ($user, $what, $how) {
> > move /share/$user/$what to /$what
> > if ($how == slave)
On Fri, 2007-04-13 at 13:58 +0200, Miklos Szeredi wrote:
> > On Wed, 2007-04-11 at 12:44 +0200, Miklos Szeredi wrote:
> > > > 1. clone the master namespace.
> > > >
> > > > 2. in the new namespace
> > > >
> > > > move the tree under /share/$me to /
> > > > for each ($user, $what,
On Fri, 2007-04-13 at 16:05 +0200, Miklos Szeredi wrote:
> > > Thinking a bit more about this, I'm quite sure most users wouldn't
> > > even want private namespaces. It would be enough to
> > >
> > > chroot /share/$USER
> > >
> > > and be done with it.
> > >
> > > Private namespaces are only
>
> "Serge E. Hallyn" <[EMAIL PROTECTED]> writes:
>
> > Quoting Miklos Szeredi ([EMAIL PROTECTED]):
> >> From: Miklos Szeredi <[EMAIL PROTECTED]>
> >>
> >> If CLONE_NEWNS and CLONE_NEWNS_USERMNT are given to clone(2) or
> >> unshare(2), then allow user mounts within the new namespace.
> >>
> >
On Mon, 2007-04-16 at 11:32 +0200, Miklos Szeredi wrote:
> > > Given the existence of shared subtrees allowing/denying this at the
> > > mount
> > > namespace level is silly and wrong.
> > >
> > > If we need more than just the filesystem permission checks can we
> > > make it a mount flag settable
On Mon, 2007-04-16 at 11:56 +0200, Miklos Szeredi wrote:
> > > > Also for bind-mount and remount operations the flag has to be propagated
> > > > down its propagation tree. Otherwise a unpriviledged mount in a shared
> > > > mount wont get reflected in its peers and slaves, leading to unidentical
d=0x6200 is the directory tree that resides under /tmp1
Signed-off-by: Ram Pai <[EMAIL PROTECTED]>
---
fs/dcache.c | 53
fs/namespace.c | 35 ++---
fs/proc/base.c | 32 +--
fs/proc/pr
> one could write a script which runs through these lines and draws 4
> > individual satellite mounts and two propagation trees, the first
> propagation
> > tree has a shared mount and a slave mount. and the second
> propagation tree has
> > just one shared mount.
> >
> >
On Mon, 2007-04-16 at 23:07 +0200, Karel Zak wrote:
> On Mon, Apr 16, 2007 at 10:39:46AM -0700, Ram Pai wrote:
>
> > This patch disambiguates multiple mount-instances of the same
> > filesystem (or part of the same filesystem), by introducing a new
> > interface /proc/m
On Tue, 2007-04-17 at 19:44 +0200, Miklos Szeredi wrote:
> > I'm a bit lost about what is currently done and who advocates for what.
> >
> > It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
> > propagated. In the /share rbind+chroot example, I assume the admin
> > would start by
On Tue, 2007-04-17 at 21:43 +0200, Miklos Szeredi wrote:
> > > > I'm a bit lost about what is currently done and who advocates for what.
> > > >
> > > > It seems to me the MNT_ALLOWUSERMNT (or whatever :) flag should be
> > > > propagated. In the /share rbind+chroot example, I assume the admin
>
On Wed, 2007-04-18 at 11:19 +0200, Miklos Szeredi wrote:
> > > 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 t
On Wed, 2007-04-18 at 21:14 +0200, Miklos Szeredi wrote:
> > As I said earlier, I see a case where two mounts that are peers of each
> > other can become un-identical if we dont propagate the "allowusermnt".
> >
> > As a practical example.
> >
> > /tmp and /mnt are peers of each other.
> > /tmp h
ny) is sitting among the options...
>
> Okay, I see there has been some discussion on this earlier, based on a
> proposal by Ram Pai, so it pretty much comes down to redesigning this
> right. I see some issues with his proposal (device numbers exported to
> userspace in text form should b
On Thu, 2007-06-21 at 09:29 -0700, H. Peter Anvin wrote:
> Ram Pai wrote:
> >
> > Peter, I am not working on it currently. But i am interested in getting
> > it done. I have the seed set of patches which had Al Viro's ideas
> > incorporated. Infact those patches
On Thu, 2007-06-21 at 10:31 -0700, H. Peter Anvin wrote:
> Ram Pai wrote:
> >
> > Peter, I am not working on it currently. But i am interested in getting
> > it done. I have the seed set of patches which had Al Viro's ideas
> > incorporated. Infact those patches
On Fri, 2007-06-22 at 00:06 -0700, H. Peter Anvin wrote:
> Ram Pai wrote:
> >
> > the second patch made a /proc/propagation interface which had almost the
> > same fields, but also added fields to show the propagation type of the
> > mount as well as pointers to its pe
ectory
of this mount.
And finally the mount with id c1208c08 is its parent.
Signed-off-by: Ram Pai <[EMAIL PROTECTED]>
---
fs/dcache.c | 53 +++
fs/namespace.c | 25 ++
fs/pnode.c | 22
On Wed, 2007-07-11 at 11:24 +0100, Christoph Hellwig wrote:
> On Sat, Jun 30, 2007 at 08:56:02AM -0400, H. Peter Anvin wrote:
> > Is that conjecture, or do you have evidence to that effect? Most users
> > of this file are using it via the glibc interfaces, and there probably
> > aren't all that
And finally the mount with id 16 is its parent.
Testing: symlinked /etc/mtab to /proc/mounts and did some mount and df
commands. They worked normally.
Signed-off-by: Ram Pai <[EMAIL PROTECTED]>
---
fs/dcache.c | 53 +++
fs/namespace.c
Adds the ability to unclone a vfs tree. A uncloned vfs tree will not be
clonnable, and hence cannot be bind/rbind to any other mountpoint.
RP
fs/namespace.c| 15 ++-
include/linux/fs.h|1 +
include/linux/mount.h | 15 +++
3 files changed, 30 insert
code Optimization for pnode.c
fs/pnode.c | 478 -
1 files changed, 224 insertions(+), 254 deletions(-)
Index: 2.6.12.work1/fs/pnode.c
===
--- 2.6.12.work1.orig/fs/pnode.
Enclosed 8 patches that implement shared subtree functionality as
detailed in Al Viro's RFC found at http://lwn.net/Articles/119232/
I have incorporated all the comments received earlier in first round. Thanks
to Miklos and Pekka for the valuable comments. Also I have optimized lots of
code, esp
adds support for mount/umount propogation for autofs initiated operations,
RP
fs/namespace.c| 151 +-
fs/pnode.c| 13 ++--
include/linux/pnode.h |3
3 files changed, 61 insertions(+), 106 deletions(-)
Index: 2.6.12.work
Adds ability to clone a namespace that has shared/private/slave/unclone
subtrees in it.
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c |9 +
1 files changed, 9 insertions(+)
Index: 2.6.12.work1/fs/namespace.c
This patch adds the shared/private/slave support for VFS trees.
Signed by Ram Pai ([EMAIL PROTECTED])
fs/Makefile |2
fs/dcache.c |2
fs/namespace.c| 98 +++
fs/pnode.c| 158
Adds the ability to bind/rbind a shared/private/slave subtree and set up
propogation wherever needed.
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c| 559 --
fs/pnode.c| 416
Adds ability to move a shared/private/slave/unclone tree to any other
shared/private/slave/unclone tree. Also incorporates the same behavior
for pivot_root()
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c | 150 +++--
1 files
Adds ability to unmount a shared/slave/unclone/private tree
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c| 68 +-
fs/pnode.c| 112 ++
include/linux/fs.h|3 +
include/linux
On Mon, 2005-07-18 at 04:06, Miklos Szeredi wrote:
> Thanks for the writeup, it helps to understand things a bit better.
> However I still don't understand a few things:
>
>
> > Section 1. mount:
> >
> > to begin with we have a the following mount tree
> >
> > root
> >
, [EMAIL PROTECTED], Janak Desai <[EMAIL PROTECTED]>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: [PATCH 0/7] shared subtree
Hi Andrew/Al Viro,
Enclosing a final set of well tested patches that implement
Al Viro's shared subtree proposal.
These p
ree. A uncloned vfs tree will not be
clonnable, and hence cannot be bind/rbind to any other mountpoint.
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c| 15 ++-
include/linux/fs.h|1 +
include/linux/mount.h | 15 +++
3 files changed, 30 insertions
gation for autofs initiated operations,
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c| 176 +++---
fs/pnode.c| 12 +--
include/linux/pnode.h |3
3 files changed, 76 insertions(+), 115 deletions(-)
Index: 2.6.12.wo
nclone/private tree
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c| 76 --
fs/pnode.c| 66 +++
include/linux/fs.h|3 +
include/linux/pnode.h |9 -
4 files change
nclone tree to any other
shared/private/slave/unclone tree. Also incorporates the same behavior
for pivot_root()
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c| 196 +++---
include/linux/mount.h |2
2 files changed, 173 inse
rivate/slave subtree and set up
propogation wherever needed.
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c| 660 --
fs/pnode.c| 235
include/linux/dcache.h|2
include/linux/fs.h
at has shared/private/slave/unclone
subtrees in it.
RP
Signed by Ram Pai ([EMAIL PROTECTED])
fs/namespace.c |9 +
1 files changed, 9 insertions(+)
Index: 2.6.12-rc6.work1/fs/namespace.c
===
--- 2.6.12-rc6.work1.o
ds the shared/private/slave support for VFS trees.
Signed by Ram Pai ([EMAIL PROTECTED])
fs/Makefile |2
fs/dcache.c |2
fs/namespace.c| 93 ++
fs/pnode.c| 441 ++
include/linux/fs.h
On Mon, 2005-07-25 at 15:44, Ram Pai wrote:
> , [EMAIL PROTECTED], Janak Desai <[EMAIL PROTECTED]>,
> linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
> Subject: [PATCH 0/7] shared subtree
>
> Hi Andrew/Al Viro,
>
> Enclosing a final set of well te
On Wed, 2005-07-27 at 12:54, Miklos Szeredi wrote:
> > +static int do_make_shared(struct vfsmount *mnt)
> > +{
> > + int err=0;
> > + struct vfspnode *old_pnode = NULL;
> > + /*
> > +* if the mount is already a slave mount,
> > +* allocate a new pnode and make it
> > +* a slave pn
On Wed, 2005-07-27 at 12:13, Miklos Szeredi wrote:
> > @@ -54,7 +55,7 @@ static inline unsigned long hash(struct
> >
> > struct vfsmount *alloc_vfsmnt(const char *name)
> > {
> > - struct vfsmount *mnt = kmem_cache_alloc(mnt_cache, GFP_KERNEL);
> > + struct vfsmount *mnt = kmem_cache_allo
Summary of the question:
Should the topmost mount be visible, or should the most recent
mount be visible?
consider the following command sequence
(1) cd /mnt
(2) mount --bind /usr /mnt
(3) mount --bind /bin /mnt
(4) mount --bind /var .
after step 1, the pwd of the process is poin
On Thu, 2005-07-28 at 04:56, Miklos Szeredi wrote:
> > Here is a scenario with shared subtree. Sorry it is complex.
> >
> >
> > mount --bind /mnt /mnt
> > mount --make-shared /mnt
> > mkdir -p /mnt/p
> > mount --bind /usr /mnt/1
> > mount --bind /mnt /mnt/2
> >
> > At this stage the mount at /
On Thu, 2005-07-28 at 08:58, Miklos Szeredi wrote:
> > step 1: mount --bind /mnt /mnt
> > a new mount 'A' is created at /mnt
> >
> > step 2: mount --make-shared /mnt
> >mounts under 'A' are made shared. But in this case
> >there are no other mounts. So only 'A' will
On Thu, 2005-07-28 at 12:30, Miklos Szeredi wrote:
> > no. there is no asymmetry as such. the propogations are working the way
> > they are meant to. But the confusion arises because of the mount lookup
> > symantics. The reason Avantika(who is doing shared subtree testing),
> > had this exact con
On Thu, 2005-07-28 at 13:35, Bryan Henderson wrote:
> It wouldn't surprise me if someone is depending on mount over ".". But
> I'd be surprised if someone is doing it to a directory that's already been
> mounted over (such that the stacking behavior is relevant). That seems
> really eccentri
On Thu, 2005-07-28 at 13:44, Miklos Szeredi wrote:
> > I am not surprised when mounts on /mnt/1 do not propogate to /mnt/2/1
> > This is expected, and I am perfectly happy. Because the mount is
> > attempted on 'B' and 'B' has nobody to propogate to.
> >
> > when mount on /mnt/2/1 (i.e on C at den
On Thu, 2005-07-28 at 15:27, Bryan Henderson wrote:
> >Bryan, what would you expect the behavior to be when somebody mounts on
> >a directory what is already mounted over?
>
> Well, I've tried to beg the question. I said I don't think it's
> meaningful to mount over a directory; that one actual
On Thu, 2005-07-28 at 02:57, Miklos Szeredi wrote:
> > > This is an example, where having struct pnode just complicates things.
> > > If there was no struct pnode, this function would be just one line:
> > > setting the shared flag.
> > So your comment is mostly about getting rid of pnode and distr
On Fri, 2005-07-29 at 22:39, Miklos Szeredi wrote:
> > > static struct vfsmount *propagation_next(struct vfsmount *p,
> > >struct vfsmount *base)
> > > {
> > > /* first iterate over the slaves */
> > > if (!list_empty(&p->mnt_slave_list))
> > > retu
On Thu, 2005-08-18 at 12:40, Dave Schwartz wrote:
> Hi list,
>
> Not too sure if this is the right forum to ask this question but since
> my requirement is around linux filesystems, I shall take this liberty
> to post my question.
>
> My requirement is to develop a kernel/user space module to ad
t argc, char *argv[])
{
if(clone(myfunc, somemem, CLONE_NEWNS|SIGCHLD, NULL)) {
wait(NULL);
} else {
printf("clone failed\n");
}
printf("exit\n");
}
Hope this helps,
RP
>
> Gracias,
> decebel
>
&
Ok. I have shared subtree patches getting ready for review. I have
totally revamped the code from what I had sent last time, incorporating
all valuable comments Miklos had made. Offcourse I am yet to finish a
document that Andrew Morton had requested.
The patch snapshot at:
http://www.sudhaa.com/~
most people would be happier with a new file, instead of
> extending /proc/mounts.
>
> This patch is the first attempt at doing that, as well as fixing the
> issues found in the previous submission.
>
> Thanks,
> Miklos
>
> ---
> From: Ram Pai <[EMAIL PROTECTED]
On Mon, 2008-01-21 at 22:25 +0100, Miklos Szeredi wrote:
> > You have removed the code that checked if the peer or
> > master mount was in the same namespace before reporting their
> > corresponding mount-ids. One downside of that approach is the
> > user will see an mount_id in the
On Thu, 2008-01-31 at 10:17 +0100, Miklos Szeredi wrote:
> > > From: Ram Pai <[EMAIL PROTECTED]>
...snipped...
> IDR ids are 'int' but they are always positive (AFAICT), but yeah,
> maybe this is confusing.
>
> > The new exported-to-everyone dentry_path
CONFIG_PROC_FS=n, since it was
impossible to disable CONFIG_PROC_FS. Looking for ideas on how to disable
CONFIG_PROC_FS.
Signed-off-by: Ram Pai <[EMAIL PROTECTED]>
---
fs/dcache.c | 59 +++
fs/namespace.c |2
On Mon, 2008-02-04 at 01:28 -0800, Andrew Morton wrote:
> On Mon, 04 Feb 2008 01:15:05 -0800 Ram Pai <[EMAIL PROTECTED]> wrote:
>
> > 1) reports deleted inode in dentry_path() consistent with that in __d_path()
> > 2) modified __d_path() to use prepend(), reducing the
On Wed, 2008-02-20 at 09:31 -0700, Matthew Wilcox wrote:
> On Wed, Feb 20, 2008 at 04:04:22PM +, Al Viro wrote:
> > It's less about the form of representation (after all, we generate poll
> > events when contents of that sucker changes, so one *can* get a consistent
> > snapshot of the entire t
On Wed, 2008-02-20 at 17:27 +0100, Miklos Szeredi wrote:
> > On Wed, Feb 20, 2008 at 04:39:15PM +0100, Miklos Szeredi wrote:
> > > > mountinfo - IMO needs a sane discussion of what and how should be shown
> > > > wrt propagation state
> > >
> > > Here's my take on the matter.
> > >
> > > The prop
62 matches
Mail list logo
